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ABSTRACT 


This  report  serves  as  the  language  manual  for  OLGA,  a 
powerful  programming  language  for  the  PDP-11  requiring  only  8k 
words  of  memory  and  teletype.  An  overview  of  OLGA  is  followed  by 
a  detailed  description  of  its  syntax  and  semantics.  Appendices 
are  provided  to  explain  how  to  compile  and  run  OLGA  programs. 
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CHAPTER  1 
Introduct ion 

This  reference  manual  describes  OLGA  for  the  PDP/11,  and 
provides  the  user  with  the  required  information  for  writing 
programs  in  the  OLGA  language. 

1.1  Programming  System 

The  OLGA  programming  system  is  composed  of  two  parts:  the 
language  and  the  compiler.  The  language  is  composed  of  reserved 
key  words,  expressions,  and  operators,  which  are  used  to  write 
the  source  program  as  a  sequence  of  statements.  It  is  summarized 
in  the  next  section  and  it  is  described  more  extensively  in  the 
remaining  Chapters  of  this  manual. 

The  OLGA  compiler  analyzes  the  source  program  statements  and 
transforms  them  into  PDP/11  machine  language.  This  form  is  known 
as  the  object  program.  In  addition,  the  compiler  produces  a 
listing  of  the  source  program  together  with  messages  describing 
all  the  errors  detected  by  the  compiler  in  the  source  program. 

1.2  Notation  used  in  the  Manual: 

The  syntax  of  the  OLGA  language  is  given  by  a  modified  Backus 
Normal  Form  of  description. 

The  following  standards  are  used  in  the  modified  Backus 
Normal  description: 

1)  Lower  case  letters  indicate  nonterminal  symbols. 

2)  The  following  special  characters  are  used  in  the  following 
ways : 

(i)  The  "  character  encloses  terminal  symbols.  Terminal 
symbols  are  keywords  and  special  characters  which  are 
part  of  the  syntactic  definition.  Keywords  are  written 
in  upper  case  letters. 

(ii)  The  "  character  is  part  of  the  syntactic  definition 
of  bits  constants. 

(iii)  The  underscore  (_)  is  used  when  two  or  more  words 
are  used  as  a  nonterminal  symbol. 

(iv)  The  vertical  stroke  (|)  indicates  an  alternative 
syntactic  expression  which  may  be  used  in  the  specified 
context . 

(v)  The  word  empty  is  used  and  reserved  to  indicate  an 
empty  alternative. 

3)  The  following  abbreviations  are  used: 

X_List  is  notationally  always  X  |  X_List  X 
X_Elist  is  notationally  always  empty  |  X_List  X 
X_Sequence  is  notationally  always  X  |  X_Sequence  ,,,M  X 
X,  above,  is  a  non  terminal  symbol. 
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Example: 

declaration  block 


declare_statement 
end  declare  statement 


declare_statement 
declaration  statement_Elist 
end_declare_statement 
"DECLARE" 

"END"  "DECLARE" 


DECLARE  aird  END  are  terminal  symbols.  Declaration_block, 
declare_st.atement ,  and  end_declare_statement  are  non  terminal 
symbols.  The  first  replacement  rule  states  that  a 
declaration_block  is  made  up  of  the  nonterminal  symbols  in  the 
following  or&^r: 


1 .  The  declare_statement 

2.  A  possibly  empty  list  of  declaration_statements 

3.  The  en-d  declare  statement 


The  second  replacement  rule  states  that  a  declare_statement  is 
made  up  of  the  terminal  symbol  DECLARE. 

The  third  replacement  rule  states  that  an  end_declare_state ment 
is  made  up  of  “the  terminal  symbols  END  and  DECLARE. 
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CHAPTER  2 

Summary  of  the  OLGA  Language 

OLGA  contains  various  abstraction  mechanisms  to  encourage  a 
structured  approach  toJ programming.  It  also  contains  a  rich 
variety  of  control  structures  and  data  structures  to  provide  the 
user  with  a  wide  selection  of  implementation  alternatives. 

2.1  Program  Structures 

An  OLGA  program  is  made  up  of  a  list  of  abstractions  and 
modules  which  define  the  computing  task  to  be  performed.  An 
abstraction  in  OLGA  can  be  either  a  procedure,  a  function,  an 
operator,  a  data  block,  or  a  user  defined  type.  A  module  is  used 
to  group  related  abstractions  and  to  isolate  these  abstractions 
from  the  environment  outside  the  module. 

A  procedure  is  a  subprogram  that  does  not  directly  return  a 
value  to  the  calling  program.  Function  subprograms  and  operator 
subprograms  always  return  values  to  the  calling  program,  but  they 
differ  from  each  other  in  the  way  they  are  employed  in 
expressions.  A  function  is  called  in  an  expression  by  writing 
its  name  followed  by  its  argument  list  enclosed  by  brackets.  An 
operator  is  called  in  an  expression  either  in  a  monadic  operator 
notation  or  in  a  dyadic  operator  notation,  i.e.,  the  name  of  the 
operator  appears  before  its  operand  or  it  appears  between  its  two 
operands. 

A  serially  reusable  subprogram  may  not  call  itself  either 
directly  or  indirectly  through  other  subprograms.  A  reentrant 
subprogram  may  call  itself  either  directly  or  indirectly  through 
other  subprograms.  Subprograms  are  assumed  to  be  serially 
reusable  unless  they  are  defined  to  be  reentrant. 

A  procedure,  a  function,  or  an  operator  may  not  contain  the 
definition  of  another  procedure,  function,  or  operator. 
Subprograms  can  communicate  values  or  share  variables  either 
through  the  use  of  arguments  or  through  the  use  of  data  blocks. 
A  data  block  is  a  named  collection  of  variables  which  can  be 
referenced  by  one  or  more  subprograms. 

OLGA  allows  the  user  to  define  his  own  data  types.  In  a  type 
definition,  a  name  is  given  to  a  data  type  built  from  the  system 
defined  data  types. 

A  module  is  used  to  enclose  related  abstractions  (procedures, 
functions,  operators,  data  blocks,  and  user  defined  types).  A 
module,  in  effect,  screens  part  of  the  complexity  that  it 
presents  the  environment  outside  the  module;  the  only 
abstractions  of  the  module  that  can  be  used  outside  are  those 
declared  in  an  EXPORTS  clause.  A  module  also  screens  part  of  the 
complexity  of  the  outside  environment;  the  only  abstractions  from 
the  environment  outside  the  module  that  can  be  used  inside  are 
declared  in  an  IMPORTS  clause. 
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Literal  definitions  provide  the  user  with  a  convenient  method 
to  perform  textual  substitution  in  his  source  program.  Literals 
follow  the  same  scope  rules  as  abstractions  when  they  are  used  in 
modules. 

2.2  Data  Structures 

There  are  four  basic  data  types  in  the  language.  They  are 
integer,  bits,  character,  and  pointer.  An  integer  is  a  number 
which  cannot  be  greater  than  an  implementation  dependent  number. 
A  bits  value  is  a  fixed  length  contiguous  sequence  of  binary 
digits  that  is  treated  as  a  single  data  item,  A  character  value 
is  a  single  character  which  belongs  to  the  ASCII  character  set. 
Pointer  values  are  defined  below. 

A  variable  is  a  quantity  that  may  assume  different  values  at 
different  stages  of  execution  of  a  program.  The  type  of  every 
variable  in  a  program  must  be  declared  before  the  variable  is 
used.  Integer  variables,  bits  variables,  and  character  variables 
may  assume,  respectively,  integer,  bits,  and  character  values. 

A  pointer  variable  may  assume  pointer  values.  A  pointer 
value,  and  hence  a  pointer  variable,  is  effectively  a  reference 
to  the  value  of  a  variable.  A  pointer  variable  may  only  point  at 
one  type  of  variable,  namely  the  one  declared  in  the  pointer 
declaration. 

An  array  is  a  group  of  values  of  the  same  type  arranged  in 
order.  Elements  of  arrays  may  be  either  integer,  bits, 
character,  or  pointer  types,  and  they  are  selected  by  a 
computable  index.  Any  lower  bound  can  be  declared.  If  it  is 
omitted,  it  is  assumed  to  be  zero. 

A  record  is  a  collection  of  quantities  grouped  under  one 
name.  Unlike  elements  of  arrays,  quantities  in  a  record,  called 
fields,  do  not  have  to  be  of  the  same  type.  A  field  of  a  record 
can  be  any  valid  OLGA  type,  including  a  record,  and  it  is 
selected  by  its  name. 

2.3  Control  Structures 

Normally,  statements  in  an  OLGA  program  are  executed 
sequentially.  The  sequential  order  of  execution  of  statements 
may  be  changed  by  using  control  statements.  They  are  the 
loop_statement,  the  when_then_statement ,  the 
if_then_else_statement,  the  case_statement ,  the  return_state ment 
and  the  exit_statement . 

The  loop_statement  is  used  to  execute  repeatedly  a  list  of 
statements  while  a  condition  is  satisfied  (while  form)  or  until  a 
condition  is  satisfied  (until  form) .  The  test  of  the  condition 
is  made  either  at  the  beginning  or  at  the  end  of  an  iteration 
depending  upon  whether  the  test  is  specified  at  the  beginning  or 
at  the  end  of  the  loop_statement.  Tests  cannot  be  specified  both 
at  the  beginning  and  at  the  end  of  the  loop_statement . 


10 


The  exit_statement  is  only  used  inside  the  loop_statement ,  and  it 
causes  the  unconditional  transfer  execution  to  the  first 
statement  that  follows  the  loop_statement. 

The  when_then_st atement  is  used  to  execute  a  statement 
conditionally.  A  bits  expression  is  evaluated  and  if  the 
rightmost  bit  of  the  result  is  one  then  the  statement  in  the  THEN 
part  is  executed.  Otherwise  execution  is  transfered  to  the 
statement  following  the  when_then_statement. 

The  if_then_else_st atement  is  used  to  execute  one  of  the  two 
statements  depending  on  a  condition.  A  bits  expression  is 
evaluated  and  if  the  rightmost  bit  of  the  result  is  one,  then  the 
statement  in  the  THEN  part  is  executed.  Otherwise,  the  statement 
in  the  ELSE  part  is  executed. 

The  case_statement  is  used  to  choose  for  execution  a 
statement  from  a  list  of  statements.  An  integer  expression  is 
evaluated  and  the  statement  chosen  for  execution  is  the  one  whose 
label  is  equal  to  the  value  of  the  expression. 


The  return_statement  is  used  inside  a  subprogram  and  it 
returns  control  and  the  value  it  computed  to  the  calling  program. 


2.4  Source  Program  Records 

0 IGA  source  program  statements,  described  in  Chapters  4,  5, 
6,  and  7,  are  written  in  source  program  records.  (A  description 
of  the  construction  of  a  source  program  is  contained  in  Appendix 
A).  A  source  program  record  may  cortain  one  or  more  statements. 

Statements  which  are  written  in  the  same  source  program 
record  have  to  be  separated  by  semicolons.  A  semicolon  is  not 
required  at  the  end  of  the  last  statement  of  a  source  program 
record.  Unless  otherwise  noted,  if  a  statement  is  written  in 
more  than  one  source  program  record,  then  there  must  be  a  # 
character  in  each  record  except  the  last  one.  All  characters 
between  the  #  and  the  end  of  the  source  program  record  are 
treated  as  comments. 


The  start  of  a  comment  is  designated  by  the  %  character. 
Once  a  comment  appears  in  a  source  program  record,  it  is  assumed 
that  the  comment  will  extend  to  the  end  of  the  record.  If  a 
source  program  record  contains  only  a  comment,  then  the  first  non 
blank  character  in  the  record  must  be  the  %  character.  A  #  in  a 
comment  is  ignored.  Comments  are  not  analyzed  by  the  compiler. 


Empty 

program  to 


source  program  records  may  be  inserted  in  the  source 
improve  the  readability. 


Except  where  otherwise  noted,  blank  characters  may  be 
inserted  anywhere  to  improve  the  readability  of  the  source 
program. 
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CHAPTER  3 

Basic  Elements  of  the  Language 


3  .  1  Constants : 

Four  types  of  constants  may  be  used  in  a  source  program: 
integer,  bits,  character,  and  pointer. 


3.1.1  Integer  Constants: 

integer  ::=  decimal_digit_List 

|  decimal_digit_List 

|  "  +  "  decimal_digit_List 


decimal_digit 


HQ  if  |  ii ^  ii  |  H2"  1 1<3"  |  <1411 1 11511 1 11511 1 11 7 11 1  "8"  |  "9" 


An  integer  constant  is  a  number.  The  magnitude  of  an  integer 
constant  must  not  be  greater  than  32767. 

Examples:  The  following  are  valid  integer  constants: 

0 

+ 1 
+  91 
91 

-327 

0004 

-000567 


The  following 
3.2 

-5D000 

5,139 


are  invalid  integer  constants: 

%  decimal  point  not  allowed 
%  exceeds  the  magnitude  permitted 
%  embedded  comma  not  allowed. 


3.1.2  Bits  Constants: 

A  bits  constant  is  a  contiguous  sequence  of  binary  digits 
that  is  treated  as  a  single  data  item.  The  number  of  binary 
digits  in  a  lpits  constant  is  fixed. 


A  bits  constant  is  written  in  a  program  as  an  octal  number 
enclosed  by  double  quotes. 

Example:  The  following  are  valid  bits  constants: 

"001" 

•1 1 777771* 

"653" 


Restriction:  The  bits  constant  must  fit  in  16  binary  digits. 

Therefore  the  octal  number  must  not  be  greater  than  177777. 

The  following  are  invalid  bits  constants 

"+1"  %  Plus  operator  not  allowed 

ii_504*»  %  Minus  operator  not  allowed 

"277777"  %  exceeds  the  permitted  size. 
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The  bits  of  a  bits  constant  are  stored  in  memory  in  the 
following  order 


15|14| 13 | 1 2 | 1 1 |10|9|8|7|6|5|4|3|2| 1|0 


Bit  0  is  called  the  low  order  bit.  The  table  below  contains 
some  bits  constants  and  the  corresponding  values  of  the  bits. 


Bits  constant 

"0" 
h  n 

117711 

"156” 

"177777" 

"124635" 

Also,  the  word  TRUE  may  b 
FALSE  may  be  used  in  place  of 
which  represent  true  and 
statements  (see  Section  5.3). 


Values  of  the  bits 

0  000  000  000  000  000 

0  000  000  000  000  001 

0  000  000  000  111  111 

0  000  000  001  101  110 

1  111  111  111  111  111 

1  010  100  110  011  101 

used  in  place  of  "1",  and  the  word 
"0".  These  are  the  bits  constants 
false  conditions  in  the  control 


3.1.3  Character  Constants: 

character_constant  ::=  "*"  character  "'" 

character  ::=  {any  ASCII  character  except  the  quote} 

%  Two  consecutive  quote  characters 
%  represent  a  quote  character 
%  constant. 


A  character  constant  is  a  single  character.  A  character 
constant  carries  symbolic  information  (as  opposed  to  a  numeric 
value  or  a  list  of  bit  values) .  A  character  constant  is  denoted 
by  a  character  enclosed  by  single  quotes. 

Examples:  The  following  are  valid  character  constants. 

' A*  %  The  character  A 

1 ' ' 1  %  The  quote  character  constant 

1  •  %  The  blank  character  constant 


The 


following  are 

1  AB  * 

•  A 


invalid  character  constants. 
%  Too  many  characters 
%  Missing  enclosing  quote 


3.1.4  Pointer  Constants 

The  only  permissible  pointer  value  that  can  be  explicitly 
written  is  the  pointer  constant  NULL.  The  use  of  pointer  values 
will  be  defined  in  Section  3.2.2. 

3.2  Variables: 

A  variable  is  a  quantity  that  may  assume  different  values  and 
that  has  a  name  by  which  it  is  referred.  The  value  of  a  variable 


13 


may  change  either  for  different  executions  of  a  program  or  at 
different  stages  within  a  program.  The  value  of  a  variable  at  a 
certain  stage  within  the  program  is  the  value  that  was  assigned 
in  the  most  recent  execution  of  a  replacement  operation  on  that 
variable.  For  example,  in  the  statement: 

C  :=  6+D 

both  C  and  D  are  variables.  After  execution  of  this  replacement 
statement,  the  value  of  C  is  6  more  than  the  last  value  assigned 
to  D.  C  will  retain  this  value  until  a  replacement_state ment 
which  assigns  a  new  value  to  C  is  executed. 

3.2.1  Variable  Names 


identifier  ::=  alphabetic_character 

|  identifier  alphabetic_character 
|  identifier  decimal^digit 
|  identifier  break_character 

alphabetic_character  : "A” | "B"| "C" | "D" |  ...  "X" | "Y” | MZ" 
break  character  ::=  "  ” 


The  name  of  a  variable  is  an  identifier.  Blanks  must  not  be 
embedded  in  an  identifier.  Two  adjacent  identifiers  must  be 
separated  by  one  or  more  blanks. 

Restrictions:  Identifiers  may  not  be  the  same  as  any  reserved 
word  and  may  not  be  the  same  as  the  names  of  the  functions  and 
procedures  provided  by  OLGA.  The  number  of  characters  in  an 
identifier  must  not  be  greater  than  9. 


Example:  The  following  are  valid  variable  names. 


JOE 

A  1 2345 
ID  NX) 


The  following 
5TH_WD 
<D_SIGN 
SYM  TAB 
THEN 


are  invalid  variable  names. 

%  First  character  must  be  alphabetic  character 
%  a)  character  is  not  an  alphabetic  character 
%  No  embedded  blanks  are  allowed 
%  THEN  is  a  reserved  word. 


3.2.2  Variable  Types 


The  type  of  a  variable  corresponds  to  the  type  of  constant 
the  variable  represents.  The  type  of  a  variable  must  be  either 
integer,  character,  bits,  or  pointer. 


3.2. 2.1  Integer  Variables 

Integer  variables  represent  quantities  that  may  assume 
integer  constant  values. 
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3. 2.  2. 2  Character  Variables 

Character  variables  represent  quantities  that  may  assume 
character  constant  values, 

3. 2. 2. 3  Bits  Variables 

Bits  variables  represent  quantities  that  may  assume  bits 
constant  values. 

3.2. 2. 4  Pointer  Variables 

A  pointer  variable  represents  a  quantity  that  may  assume 
pointer  values.  A  pointer  value,  and  hence  a  pointer  variable, 
is  effectively  a  reference  to  the  value  of  a  variable.  A  pointer 
variable  is  assigned  the  value  NULL  when  it  does  not  point  to  any 
variable. 

Example:  P  and  Q  are  pointer  variables  which  point  to  integer 
variables.  I  and  J  are  integer  variables. 

P  will  not  point  to  the  value  of  an  integer  variable  when 
the  following  assignment  is  made. 

P  :=  NULL 

P  will  point  to  the  value  of  variable  I  when  the  following 
assignment  is  made 

P  :=  REFERf I  ] 

Similarly,  Q  will  point  to  the  value  of  J  when  the  following 
assignment  is  made. 

C:=  REFER[ J  ] 

The  name  I  can  be  used  to  refer  to  the  value  of  variable  I. 
The  pointer  variable  P  can  also  be  used  to  refer  to  the  value  of 
variable  I. 

a)P  is  a  reference  to  the  value  of  I  if  P  contains  a  pointer 
to  I. 


When  a  pointer  value  is  used  to  refer  to  the  value  of  a 
variable,  the  pointer  value  is  said  to  be  dereferenced. 

To  assign  the  value  of  I  to  J,  the  following  assignment  can 
be  made: 

J  :  =  a)P 

In  the  above  example,  the  pointer  value  of  P  is  dereferenced 
and  the  resultant  value  (the  integer  value  of  I)  is  assigned  to 
J. 


3.2.3  Specifying  Variable  Types 

The  type  of  a  variable  must  be  specified  in  a  declaration 
statement  and,  in  the  case  of  a  declaration  of  a  variable  as 
beeing  of  type  pointer,  the  type  of  variable  pointed  to  must  also 
be  specified.  (See  Section  6.3.) .  The  type  of  a  variable  cannot 
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be  specified  in  an  implicit  way  such  as  using  the  first  letter  of 
the  variable  name  to  denote  the  variable  type.  Every  variable 
must  be  declared. 

3.3  Arrays  and  Subscripts 

An  array  is  a  group  of  values  of  the  same  type  arranged  in 
order.  The  whole  group  of  values  is  given  one  name.  The  name  of 
an  array  is  an  identifier.  (See  3.2.1) 

An  individual  element  of  an  array  is  selected  by  its  position 
in  the  array.  A  reference  to  an  element  is  made  in  the  following 
way: 

1 .  A  reference  to  an  array  is  made.  This  can  be  either  the 
name  of  the  array  or  the  dereferenced  value  of  a  pointer 
pointing  to  the  array.  See  Section  3. 2. 2. 4. 

2.  The  reference  in  step  1  is  followed  by  an  integer 
expression  enclosed  by  sguare  brackets.  The  integer 
expression  is  called  the  subscript.  Expressions  are 
described  in  Section  3.6. 

The  combination  of  card  punch  characters  (:  is  equivalent  to  [. 
Also,  the  combination  of  card  punch  characters  :)  is  equivalent 
to  ]. 


Example:  The 
arrays. 

M  [3] 

M  [1+1 ] 


following  are  valid  references  to  elements  of 

%  M  is  the  name  of  an 
%  array 


a)P  [4]  %  P  is  a  pointer  variable 

a)P  [1  +  1]  %  containing  a  pointer  to  an  array 

An  array  must  have  only  one  dimension. 

3.3.1  Arrangement  of  Arrays  in  Storage 

Arrays  are  stored  in  memory  in  increasing  order,  with  their 
first  elements  first.  For  example  if  M  is  an  array  with  bounds 
of  1  to  4,  then  the  four  values  appear  in  memory  as  follows: 

M  [1]  M  [2]  M  [3]  M  [4] 

3.3.2  Form  of  Subscripts 


The  subscript  must  be  a  valid  expression 
integer  value  as  opposed  to  a  character  value  or 
(Expressions  are  described  in  Section  3.6). 
subscript  expression  at  any  stage  during  program 
fall  between  the  lower  bound  and  upper  bound 
array  declaration  (See  6.3.2).  At  runtime,  a  test 
determine  whether  the  value  of  the  subscript 
declared  bounds. 


which  yields  an 
a  bit  value. 
The  value  of  a 
execution  must 
declared  in  the 
is  made  to 
falls  in  the 
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3.3.3  Subscripted  Variables 

A  simple  variable  is  a  variable  that  is  not  part  of  a  group 
of  variables  such  as  an  array  or  a  record.  (Records  are 
described  in  Section  3.4).  A  subscripted  variable  is  a  reference 
to  an  element  of  an  array.  Subscripted  variables  may  occur 
wherever  simple  variables  occur. 

3.4  Records  and  Field  Selectors 


A  record  is  a  collection  of  quantities  grouped  under  one 
name.  Unlike  elements  of  arrays,  the  quantities  in  a  record  do 
not  have  to  be  of  the  same  type.  The  name  of  a  record  is  an 
identifier  (See  Section  3.2.1  for  a  description  of  identifiers). 

A  component  of  a  record  is  called  a  field.  In  order  to  be 
able  to  refer  to  a  field  of  a  record,  a  unique  name  (an 
identifier)  called  a  field  selector  must  be  given  to  each  field 
in  the  record.  A  reference  to  a  field  of  a  record  is  made  in  the 
following  way: 

1 .  A  reference  to  a  record  is  made.  This  can  be  either  the 
name  of  the  record  or  the  dereferenced  value  of  a  pointer 
pointing  to  the  record.  (See  Section  3. 2. 2. 4  for  a 
description  of  dereferenced  pointer  values) . 

2.  The  reference  in  step  1  is  followed  by  a  dot  (".") 
character  followed  by  the  name  of  the  field  selector.  Such  a 
reference  is  called  a  field  selected  variable. 


Example:  The  following  are  valid  references  to  fields  of 

%  reference  to  the  field  called  Age 
%  in  the  record  called  Person. 

%  reference  to  the  field  called  Name 
%  reference  to  the  field  called  Height 
%  P  is  a  pointer  variable 
%  containing  a  pointer  to  a  record  which 
%  has  a  field  called  Age. 


reco  rds. 


PERSON. AGE 

PERSON. NAME 
PERSON. HEIGHT 
3)P.  AGE 


3.4.1  Arrangement  of  Records  in  Storage 

Records  are  stored  in  memory  with  the  fields  that  were  first 
declared  appearing  first.  Declaration  of  records  are  described 
in  Section  6.3.3.  For  example,  if  REC  is  a  record  which  was 
declared  to  contain  the  fields  A,  B,  C  in  that  order,  then  it 
appears  in  storage  as  follows: 

REC. A  REC.B  REC.C 

3.4.2  Form  of  Field  Selectors 

The  only  valid  form  of  a  field  selector  is  an  identifier  that 
has  been  declared  to  be  the  name  of  a  field  in  a  record 
declaration.  (See  6.3.3). 


17 


3.4.3  Field  Selected  Variables 

Field  selected  variables  (defined  in  Section  3. 4)  may  occur 
wherever  simple  variables  may  occur. 

3.5  Computational  Operators 

The  computational  operators  in  OLGA  are  of  two  kinds: 

1.  The  operators  which  are  provided  by  OLGA.  These  operators 
are: 

Or  operator  (|) 

And  operator  (&) 

Relational  operator  (<,>,=  ,-'=,<=, >=) 

Dyadic  Adding  operator  (♦,-) 

Not  operator  and  Monadic  Adding  operator  (-»,  +  ,-) 

Multiply  operator  (*,/,MOD) 

Dereferencing  operator  (S) . 

2.  The  operators  which  are  defined  by  the  programmer  (see 
section  7.4  for  a  description  of  these  operators). 
Programmer  defined  operators  are  of  two  types. 

(i)  Monadic  operators.  A  Monadic  operator  is  an  operator 

which  requires  one  operand.  A  Monadic  operator  is 
written  before  its  operand  in  an  expression.  An  example 
of  a  system  defined  Monadic  operator  is  the  unary  minus 
sign. eg: -A. 

(ii)  Dyadic  operators.  A  Dyadic  operator  is  an  operator 
which  requires  two  operands.  A  Dyadic  operator  is 
written  between  its  two  operands  in  an  expression. 
Examples  of  system  defined  Dyadic  operators  are  *,/,  and 
MOD. 

Each  operator  operates  on  operands  of  specific  types  and 
returns  a  value  of  specific  type.  For  example,  the 
multiplication  operation  requires  two  operands  of  type  integer 
and  the  result  of  a  multiplication  is  an  integer. 
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TABLE  OF  OPERATORS  PFOVIDED  BY  OLGA 


Operator  Type  of  Operands  Type  of  result  Description 


1 

bits, bits 

bits 

Or  Operator 

& 

bits , bits 

bits 

And  Operator 

<,>,  =  ,-1= 
<=,>= 

integer, integer 

bits 

Relation  Operator 

<  f  >  /  -  f  ~*=  f 

<=,>= 

char act er, character 

bits 

i 

Relation  Operator 

=f*’= 

pointer, pointer 

bits 

Relation  Operator 

-  / -,= 

bits, bits 

bits 

Relation  Operator 

+  r- 

integer, integer 

integer 

Addition, 

Subtraction 

I 

bits 

bits 

Not  Operator 

integer 

integer 

Unary  +  And  - 

* , / , MOD 

integer, integer 

integer 

Mult, Div, Modulo 

a) 

pointer 

(2) 

Dereferencing 

(1)  Operators  require  either  one  or  two  operands 

(2)  The  type  of  result  is  either  integer,  character,  bits,  array, 
or  record  depending  on  the  type  of  variable  which  is  referred. 

(3)  The  -i  character  is  represented  on  the  Teletype  by  Shift/N. 
The  |  character  is  represented  on  the  Teletype  by  !. 


3. 5. 1  Notes  on  Operators  Fesults 

Felational  operators  produce  a  result  of  type  BITS.  If  a 
relation  is  true  the  result  is  ”1"  and  if  it  is  false  "0", 
Relational  operators  are  useful  in  compound_statements  which  use 
the  bits  results  to  control  the  sequence  of  execution  of 
statements.  See  Section  5.3  for  a  description  of  the  use  of 
relational  operators  in  compound_statements. 


Bits  Fesult 
returned  if 
Felaticn  holds 


Result  returned 
if  Relation  does 
not  hold 


OP 1>OP2 

n  ii 

"0” 

OP 1>=OP2 

ii  ii 

"0” 

OP  1=0  P2 

it  'i  ii 

II  QM 

OP  1-i=0P2 

ii  ii 

II  QM 

OP 1<0P2 

ii  ^  n 

HQ" 

OP  1 <  =  0P2 

ii  ^  ii 

II  QM 

0 P 1  is  the 

first  operand. 

0P2  is  the  second  operand 

>  Greater  than  Operator 

>=  Greater  than  or  Equal  Operator 

=  Equal  Operator 

-i=  Not  Equal  Operator 

<  Less  than  Operator 
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<=  Less  than  or  Equal  Operator 

The  logical  operators  in  OLGA  are  the  And  Operator  (8)  and 
the  Or  operator  (|).  The  Or  operator  requires  two  bits  operands 
and  returns  a  bits  value  which  is  the  bit_by_bit  "ored"  value  of 
the  two  operands.  The  And  operator  requires  two  operands  of 
type  bits  and  returns  a  bits  value  which  is  the  bit_by_bit 
"anded"  value  of  the  two  operands.  The  Not  Operator  (-»)  requires 
a  bits  operand  and  returns  a  bits  value  which  is  the  bit_by_bit 
complement  value  of  the  operand. 

i 

The  logical  operators  are  useful  for  manipulating  individual 
bits  in  a  variable  of  type  bits.  To  manipulate  the  zeroth  bit  of 
a  variable  of  type  bits,  the  constant  ”1"  must  be  used  as  a  mask. 
For  example,  to  set  the  zeroth  bit  of  the  bits  variable  F  to  one, 
the  following  replacement_statement  must  be  used. 

F  :=  F  |  "1" 

To  clear  all  the  bits  except  the  zeroth  bit  of  the  variable  F, 
the  following  replacement_statement  must  be  used 

F  :=  F  6  "I" 

It  is  not  possible  to  subscript  a  variable  of  type  bits  in 
order  to  access  one  of  the  bits  of  the  variable. 

The  constants  used  as  masks  to  manipulate  the  bits  in  bits 
variables  are  shown  in  the  table  below. 

Bit  position  Bits  constant 


0 

it  'i  n 

1 

II  2  « 

2 

ii  4  it 

3 

”10" 

4 

"20" 

5 

”40" 

6 

"100" 

7 

"200" 

8 

"400" 

9 

"1000" 

10 

"2000" 

11 

"4000" 

12 

”10000" 

13 

"20000" 

14 

"40000" 

15 

"100000" 

3.6  Expressions 

An  expression  is  a  collection  of  one  or  more  constants, 
variables,  functions  (see  section  7.3),  operators  and  parentheses 
which  is  constructed  according  to  certain  rules.  Note  that  a 
single  constant  or  variable  is  an  expression. 
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An  expression  causes  a  value  to  be  calculated.  The  type  of 
value  which  is  obtained  when  an  expression  is  evaluated  depends 
on  the  expression. 


Example:  The  following  are  valid  expressions. 

A,B,C,  and  D  are  integer  variables.  The  type 
of  the  result  is  integer 
F  and  G  are  bits  variables.  The  type  of 
the  result  is  bits 

J  and  K  are  integer  variables.  The  type  of  the 
result  is  bits 

a>P  +  a)Q  %  P  and  Q  are  pointer  to  integer  variables.  The 

type  of  the  result  is  integer. 


A+B-C*  (D+2) 


F  6  G 


J  >=  K 


% 


% 

% 

% 

% 

% 


3.6.1  Rules  for  Constructing  Expressions 

The  following  are  the  rules  for  constructing 
expressions: 


1.  The  type  (s)  of  the  value (s)  used  with  an  operator  must  be 
the  type(s)  expected  by  that  operator.  For  example,  the  Or 
operator  reguires  that  both  its  operands  be  of  type  bits.  If 
either  of  the  operands  is  not  of  type  bits,  an  error  message 
will  be  produced  by  the  compiler. 

2.  An  expression  including  expressions  returning  pointer 
values  may  be  enclosed  by  parentheses. 

Example :  REC  is  a  record  that  contains  a  field  called  POINT. 
POINT  is  a  field  that  is  of  type  pointer  to  integer.  To 
reference  the  integer  the  following  expression  may  be  used: 

5)  (REC.  POINT) 


3.  Hierarchy  of  Operations:  Parentheses  may  be 
expressions  to  specify  the  order  in  which  operations 
be  computed.  Where  parentheses  are  omitted,  the 
understood  to  be  as  follows: 


used  in 
are  to 
order  is 


Most  Powerful 
(done  first) 


Least  powerful 
(done  last) 


a)  Parameterless  function  call 

b)  Pointer  dereferencing 

c)  Field  selection 

d)  Subscript  evaluation 

e)  Subscription 

f)  Argument  evaluation 

g)  Programmer  defined  Monadic  Operations 

h)  Programmer  defined  Dyadic  Operation, 
Multiplication,  Division,  and  Mod. 

i)  Unary  Plus,  Minus  and  Not 

j)  Addition  and  subtraction 

k)  Relational  operation 

l)  And  operation 

m)  Or  operation 


4.  As  an  expression  is  scanned  from  left  to  right,  no 
operation  is  completed  if  there  is  a  possibility  of  a  more 
powerful  one  being  done  first.  For  example  the  expression 
A  +  B*C  is  evaluated  as  ((C*B)  +  A). 
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5.  Within  the  same  priority,  the  operations  are  performed 
from  right  to  left.  However,  parentheses  may  be  used  to 
force  the  order  of  performance  of  operations  of  the  same 
priority.  In  the  case  where  parentheses  are  used,  the 
expression  enclosed  by  the  parentheses  is  evaluated  first. 
For  example  the  expression  A+B+C  is  evaluated  as  ( (C+B)  +  A)  • 
The  expression  A*  (B+C)  is  evaluated  as  (  (C+B) ♦A) . 

3.7  Statements: 

A  program  in  OLGA  is  composed  of  a  seqi^ence  of  statements.  There 
are  three  categories  of  statements  in  OLGA. 

1.  Replacement  statements  describe  calculations  to  be 
performed  and  which  variable  is  to  be  given  a  new  value  as  a 
result  of  the  calculations. 

2.  Control  statements  alter  the  normal  sequential  execution 
of  the  program  statements. 

3.  Declaration  statements  declare  properties  of  the  names 
appearing  in  the  program  and  enable  the  user  to  control  the 
allocation  of  storage. 
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CHAPTER  4 

Replacement  Statement 

The  replacement_statement  causes  a  value,  calculated  from  an 
expression,  to  become  the  new  value  of  a  variable. 

4 . 1  Definition 


replacemen t_statement  ::=  expression  replacement_operator 

expression 

replacement_operator  ::=  ,,:=M 

The  expression  on  the  left  hand  side  (L.H.S)  of  the 
replacement  operator  must  be  a  reference  to  a  variable.  The 
expression  on  the  right  hand  side  (R.H.S.)  of  the  replacement 
operator  must  yield,  when  it  is  evaluated,  a  value  that  is  of  the 
same  type  as  the  variable  referenced  on  the  L.H.S.  If  the  types 
are  not  the  same,  then  the  compiler  will  produce  an  error 
message. 


The  expression  on  the  L.H.S.  of  the  replacement  operator  must 
be  one  of  the  following: 

1 .  A  simple  variable 

Example:  A,B,C,Q,P  f  A,B,C,Q,P  are  names  of  simple 

%  variables. 


2.  A  subscripted  variable 

Example:  ARR[10],  ARR[I+J[10]]  %  ARR  and  J  are  arrays  of 

%  integers. 

%  I  is  a  variable  of  type 
%  integer. 


3.  A  field  selected  variable 

Example:  REC. AGE,  REC. HEIGHT 


%  REC  is  a  record  that  has 
%  fields  called  AGE  and 
%  HEIGHT 


4.  A  dereferenced  pointer  value 

Example:  a)P  %  P  is  a  variable  of  type  pointer  to 

%  integer. 

a)Q  %  Q  is  a  variable  of  type  pointer  to 

%  character. 

(SR). AGE  %  R  is  a  variable  of  type  pointer  to 

%  record.  The  record  has  a  field  called 
%  AGE. 


The  execution  of  a  replacement_st atement  proceeds  as  follows: 

1.  The  expression  on  the  L.H.S.  of  the  replacement  operator 
is  evaluated  to  yield  a  reference  to  a  variable. 

2.  The  expression  on  the  R.H.S.  of  the  replacement  operator 
is  evaluated  to  yield  a  value. 

3.  The  value  that  is  calculated  in  step  2  is  assigned  to  the 
variable  that  is  referenced  in  step  1, 
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Examples:  The  following  are  valid  replacement_statements 


I 

A[I] 
REC.  B 

P 
5)  P 

(3Q)  .B 


D 


J+4  %  I  and  J  are  integer  variables 

'Z'  %  A  is  an  array  of  characters 

'B'  %  REC  is  a  record  which  contains  a  character 

%  field  called  B. 

REFER[ I ]  %  P  is  a  variable  of  type  pointer  to  Integer. 
4  %  The  value, 4,  is  assigned  to  the  variable 

%  referenced  by  P 

1 C*  %  Q  is  a  variable  of  type  pointer  to  record. 

%  The  record  contains  a  character  field  called 
%  B. 

"377"SF  %  D  and  F  are  bits  variables. 


Rules : 

1.  It  is  prohibited  to  use  a  variable  in  an  expression  on  the 
R.H.S.  of  a  replacement  operator  if  the  variable  has  not  been 
assigned  a  value  previously. 


2.  It  is  prohibited  to  dereference  a  pointer  if  the  pointer 
has  the  NOIL  value  or  if  the  pointer  has  not  been  assigned  a 
value  previously. 


At  runtime,  tests  are  NOT  made  to  detect  violations  of  these 
rules  in  a  program. 

4.2  Assignment  of  Character  Strings 


There  is  one  special  type  of  replacemen t_stateme nt  which 
causes  a  number  of  character  constants  to  be  assigned  to  a 
corresponding  number  of  elements  of  an  array  of  characters.  The 
characters  which  make  up  a  character  string  are  assigned  to 
elements  of  an  array  of  characters. 

A  character  string  is  a  list  of  character  values.  If  a 
character  string  extends  into  the  next  input  record  (card) ,  then 
the  last  non  blank  character  on  the  first  input  record  is 
followed  by  the  first  character  on  the  next  record,  the  end  of 
record  is  not  included  in  the  string. 

Example:  The  following  are  valid  character  strings. 

' A  HOOSE ' 

*  DON  *  1 T  FORGET  THE  QUOTE' 

The  following  are  invalid  character  strings. 

'BAD  STRING  %  Missing  enclosing  guote 

The  assignment  of  character  strings  to  arrays  of  characters 
will  be  illustrated  by  an  example. 

VECTOR  is  an  array  of  characters.  The  programmer  may  want  to 
assign  the  character  'A'  to  VECTOR[0],  'B'  to  VECTOR[ 1  ],  'C'  to 

VECTOR[  2  ]  and  '  D'  to  VECT0R[3].  The  programmer  can  do  this  in 
two  ways: 
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1.  VECTORf  0  ]  :=  'A' 

VECTORf  1  ]  :=  '  B« 

VECTOR[  2]  :=  •  C1 
VECTOR[  3  ]  :=  '  D  * 

2.  VECTOR  :=  ' ABCD' 

The  above  two  methods  have  the  identical  effect.  Either 
method  will  cause  'A', 'B'j'C',  and  'D'  to  be  assigned 
respectively  to  the  first  four  elements  of  VECTOR. 

If  the  programmer  had  written  instead: 

VECTORf  5 ]  :=  'ABCD' 

then  this  in  equivalent  to: 

VECTOR[  5  ]  :=  'A* 

VECTOR[  6  ]  :=  'B' 

VECTORf  7  ]  :=  'C 
VECTOR[  8  ]  :=  'D' 

Restriction:  A  character  string  may  appear  only  in  the 
replacement_statements  described  above  or  in  the  argument  list  of 
a  procedure,  function  or  operator  where  an  array  of  characters  is 
expected.  If  the  name  of  an  array  is  used  without  any  subscript, 
then  the  array  MUST  have  a  lower  bound  of  zero. 


CHAPTER  5 

Control  Statements 


5. 1  Introduction 

Normally,  statements  in  OLGA  are  executed  sequentially.  The 
sequential  order  of  execution  of  statements  may  be  changed  by 
using  control  statements.  Control  statements  allow  iterative 
execution  of  a  list  of  statements  (loop_statement)  and  selective 
execution  of  a  statement  from  a  list  of  statements  (when-then 
statement,  if_then_else_statement,  and  case_statement) . 

5.2  Null_statements 

Null_statements  are  statements  which  do  not  produce 
instructions  in  the  object  program  and  as  a  result  have  no  effect 
on  the  computation.  In  OLGA,  statements  which  do  not  contain 
source  code  are  null_statements.  For  example,  a  null_state ment 
occurs  when  there  are  two  consecutive  semicolons  in  the  source 
program.  (See  the  section  2.4  for  a  description  of  the  records 
which  contain  the  source  program.). 

5.3  Compound_Statements 

A  compound_statement  (as  opposed  to  a  simple_sta teme nt)  is  a 
statement  which  contains  other  statements  within  itself. 
Examples  of  compound_statements  are  the  loop_stateme nt ,  the 
case_statement ,  the  if _then_else_statement ,  and  the 

when_then_statement.  An  example  of  a  simple_statement  is  the 
r ep lac erne nt_st ate ment . 

5.3.1  When_then_statement 

When_then_statement  :  :=  '’WHEN"  expression 

"THEN"  executable_statement 

The  when_then_statement  is  used  to  execute  a  statement 
conditionally.  The  bit  expression  following  the  key  word  WHEN  is 
evaluated  and  if  the  low  order  bit  of  the  result  is  one,  the 
statement  following  the  key  word  THEN  is  executed.  Otherwise 
execution  is  transfered  to  the  statement  that  follows  the 
when_then_statement. 

The  expression  following  the  key  word  WHEN  must  yield,  when 
it  is  evaluated,  a  value  cf  type  bits.  If  the  value  is  not  of 
type  bits,  then  the  compiler  will  produce  an  error  message. 

The  statement  following  the  key  word  THEN  must  be  an 
executable  statement.  Executable_statements  are  described  in 
Chapter  1 1 . 

Execution  of  the  when_then_statement  proceeds  as  follows: 

1.  The  bit  expression  following  the  key  word  WHEN  is 

evaluated. 
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2.  If  the  low  order  bit  of  the  bit  expression  is  one,  then 
the  statement  following  the  keyword  THEN  is  executed  and 
execution  proceeds  normally  afterwards.  If  the  low  order  bit 
of  the  bit  expression  is  zero,  then  the  statement  following 
the  keyword  THEN  is  not  executed  and  control  is  transfered 
instead  to  the  statement  that  follows  the 
when  then  statement. 


A  semicolon  or  the  physical  end  of  a  source  program  record 
may  appear  between  the  expression  following  the  key  word  WHEN  and 
the  key  word  THEN  in  a  when_then_statement.  As  a  result,  a 
continuation  mark  is  not  needed  if  a  when_then_state ment  is 
written  in  more  than  one  source  program  record  with: 

1 .  The  WHEN  key  word  and  the  expression  written  on  one  source 
program  record. 

2.  The  THEN  key  word  and  the  executable_statement  written  on 
the  following  source  program  record. 

A  continuation  mark  is  needed  in  the  other  cases  of  a 
when_then_statement  extending  into  the  next  source  record.  In 
particular,  if  the  THEN  keyword  is  written  in  one  source  record 
and  its  execut able_st atement  is  written  in  the  next  one,  then  a 
continuation  mark  must  appear  at  the  end  of  the  source  record 
containing  THEN. 

Examples:  The  following  are  valid  examples  of  the 
when  then  statement. 


WHEN  K> 1 0 
THEN  J: =1-5 


WHEN  B 

THEN  K: =K+1 


WHEN  B 

THEN  K:=K+1 

WHEN  B 
THEN 


WHEN  E 

THEN  WHEN  C 

WHEN  B  6  C 
THEN  A: =A+1 


%  If  K>  1 0  is  true  (low  order  bit  of  the  result 
%  is  one.  See  Sect.  3.  5)  then  the  replacement 
%  statement  is  executed. 

%  B  is  a  variable  of  type  bits 
%  If  the  low  order  bit  of  B  is  one  then  K 
%  is  incremented. 

%  Same  as  above  but 
%  in  one  physical  record. 

%  The  statement  following  the  key  word  THEN  is 
%  a  null  statement  (empty) . 


%  A  When_then_state ment  contains  another 
THEN  A:=A+1  %  When_then  Statement 

%  The  previous  example  has  the  identical 
%  effect  as  this  example.  This  is  the 
%  preferred  form. 
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5.3.2  If_then_else_statement 

if_then_else_statement  ::=  "IF"  expression 

"THEN"  executable_statement 
"ELSE"  executable_stat ement 

The  if_then_else_statement  is  used  to  execute  one  of  two 
statements  depending  on  the  value  of  a  bit  expression.  The  bit 
expression  following  the  key  word  IF  is  evaluated  and  if  the  low 
order  bit  is  one,  the  statement  following  the  key  word  THEN  is 
executed.  Otherwise  execution  is  transfered  to  the  statement 
following  the  key  word  ELSE.  In  both  cases,  the  statement  that 
is  executed  next  is  the  statement  that  follows  the 
if_then_else_s tat ement. 

The  expression  following  the  key  word  IF  must  yield,  when  it 
is  evaluated,  a  value  of  type  bits.  If  the  value  is  not  of  type 
bits,  then  the  compiler  will  produce  an  error_message . 

The  statement  following  the  key  word  THEN  must  be  an 
executable  statement.  Executable_statements  are  described  in 
Chapter  11. 

The  statement  following  the  key  word  ELSE  must  also  be  an 
executable  statement. 

Execution  of  the  if_then_else_ statement  proceeds  as  follows: 

1.  The  bit  expression  following  the  key  word  IF  is  evaluated. 

2.  If  the  low  order  bit  of  the  bit  expression  is  one,  then 
the  statement  following  the  key  word  THEN  is  executed.  If 
the  lew  order  bit  of  the  bit  expression  is  zero,  then  the 
statement  following  the  key  word  ELSE  is  executed. 

3.  In  both  cases,  the  statement  that  is  executed  next  is  the 
statement  that  follows  the  if  then  else  statement. 


A  semicolon  or  the  physical  end  of  a  source  program  record 
may  appear  between: 

(1)  The  expression  following  the  key  word  IF  and  the  key  word 
THEN 

or  (2)  The  statement  following  the  key  word  THEN  and  the  key 
word  ELSE. 

As  a  result,  continuation  marks  are  not  needed  if  an 
if_then_else_statement  is  written  in  more  than  one  source  program 
record  with: 

(1)  The  IF  key  word  and  the  bit  expression  written  on  one 
source  program  record. 

(2)  The  THEN  key  word  and  its  executable_statement  written  on 
another  source  program  record. 

(3)  The  ELSE  key  word  and  its  executable_statemen t  written  on 
a  third  source  program  record. 
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A  continuation  mark  is  needed  in  the  other  cases  of  an 
if_then_else_statement  extending  into  the  next  source  record.  In 
particular,  if  the  THEN  keyword  is  written  in  one  source  record 
and  its  executable_statement  is  written  in  the  next  one,  then  a 
continuation  mark  must  appear  at  the  end  of  the  source  record 
containing  THEN.  Also,  if  the  ELSE  keyword  is  written  in  one 
source  record  and  its  executable_statement  is  written  in  the  next 
one,  then  a  continuation  mark  must  appear  at  the  end  of  the 
source  record  containing  ELSE. 

Examples:  The  following  are  valid  if_then_else_statements . 

IF  B  %  B  is  a  variable  of  type  bits 

THEN  A:=A+1  %  If  the  low  order  bit  of  B  is  one  then  A 

ELSE  J:=J+1  %  is  incremented,  otherwise  J  is  incremented. 

IF  B  THEN  A: =  A  +  1  ELSE  J:=J+1 

%  Same  as  above  except  in  one  physical  record. 


5.3.3  Case_statement 

case_statement  ::=  case_heading  alterna tives_List 

"ESAC" 


The  case_statement  is  used  to  choose  for  execution  a 
statement  from  a  list  of  statements.  An  integer  expression  is 
evaluated  and  the  statement  selected  for  execution  is  the  one 
whose  label  is  equal  to  the  value  of  the  expression. 


Example:  The  following  is  a  valid  case_statement 


CASE  1+1  LIMIT  3  ELSE  2 


0: 

% 

any 

ex  ecutable_ 

statement 

appears 

here 

1: 

% 

any 

executable_ 

statement 

appears 

here 

2: 

% 

any 

executable_ 

st atement 

appears 

here 

3: 

% 

any 

executable 

statement 

appears 

here 

ESAC 


5. 3. 3.1  Case_heading 

case_heading  : :=  "CASE”  expression  "LIMIT"  integer 

"ELSE"  integer 

The  expression  in  the  case_heading  must  yield,  when  it  is 
evaluated,  a  value  of  type  integer.  The  integer  following  the 
keyword  "LIMIT"  is  the  label  with  the  greatest  numerical  value 
that  is  used  in  the  case_statement.  The  integer  following  the 
keyword  "ELSE"  is  the  label  of  the  statement  which  will  be 
executed  if  the  value  of  the  expression  is  outside  the  allowable 


range . 
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5.3. 3.2  Alternatives 

alternatives : :=  numer ical_label_List  executable_state ment 
numerical_label: : =  integer  ":" 

Each  of  the  alternatives  in  a  ca se_statement  must  be  labeled 
with  an  integer.  An  alternative  is  an  executable_state ment 
labeled  by  one  or  more  numerical  labels. 


The  keyword  ESAC  signals  the  end  of  the  case_statement. 
Execution  of  the  case_sta tement  proceeds  as  follows: 

1.  The  expression  in  the  case_heading  is  evaluated. 

2.  The  statement  that  is  executed  next  is  the  alternative 
whose  label  is  equal  to  the  value  of  the  expression  evaluated 
in  step  1.  If  the  value  of  the  expression  is  not  equal  to 
any  of  the  labels,  then  the  alternative  that  is  executed  is 
the  one  whose  label  is  the  integer  following  the  else  in  the 
case_heading. 

3.  After  the  execution  of  the  selected  alternative,  control 
is  transferred  to  the  statement  which  follows  the 
case_statement . 

Restrictions: 


1.  The  integers  used  as  labels  in  the  case  statement  must  be 
the  set  of  integers  from  zero  to  the  limit  declared  in  the 
case_heading.  (The  limit  is  the  integer  following  "LIMIT"  in 
the  case^heading)  .  Labels  must  not  be  negative  numbers. 

2.  The  labels  must  appear  in  the  case_statement  in  order  of 
increasing  size. 


A  semicolon  or  the  physical  end  of  the  source  program  record 
must  separate  the  case_heading  from  the  first  alternative.  The 
alternatives  of  a  case_stateme nt  are  statements  themselves  and 
must  be  terminated  by  either  semicolons  or  the  physical  ends  of 
source  program  records  (See  Section  2.4).  A  semicolon  or  the 
physical  end  of  a  source  program  record  may  appear,  optionally, 
between  the  last  alternative  and  the  key  word  ESAC. 

Examples:  The  following  is  a  valid  case_statement 
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CASE  A[ 1  +  5  ]  LIMIT  6  ELSE  2 
0: 

1:  %  Any  executable_statement 

2:  %  may  appear  as  an  alternative 

3:  4: 

5:  ;  6: 

ESAC 

In  the  case_stat ement  shown  above,  label  3  and  label  4  share 
the  same  executable_state ment .  Hence,  if  the  integer  expression 
following  the  keyword  "CASE”  in  the  case_heading  is  equal  to 
either  3  or  4,  then  the  alternative  that  is  executed  is  the 
executable_statement  labeled  with  the  integers  3  and  4. 

In  the  case_statement  shown  above,  the  alternative  with  label 
5  is  a  null_statement .  Hence  executing  the  case_statement  with 
the  integer  expression  following  the  keyword  "CASE"  equal  to  5  is 
equivalent  to  executing  a  null_st atement .  (See  Section  5.2  for  a 
description  of  null_state ment s) . 

The  following  are  invalid  case_statements. 

CASE  J+5  LIMIT  3  ELSE  3 
1:  % 

2:  % 

3: 

ESAC 

CASE  J-5  LIMIT  3 
0: 

2: 

1: 

3: 

ESAC 

5.3.4  Loop_Statement 

loop_statement : :=  loop_head 

executable_st atement_Elist 
loop_end 

The  loop_statement  is  used  to  execute  repeatedly  a  list  of 
executable  statements.  The  list  of  executable_st atements  ds 
executed  repeatedly  while  a  condition  is  satisfied  (while  form) 
or  until  a  condition  is  satisfied  (until  form) .  The  test  of  the 
condition  is  made  either  at  the  beginning  or  at  the  end  of  an 
iteration  depending  upon  whether  the  test  is  specified  in  the 
loop_head  or  in  the  loop_end.  Tests  cannot  be  specified  both  in 
the  loop_head  and  in  the  loop_end. 

5. 3. 4. 1  Loop_head 

loop_head  ::=  "LOOP" 

|  "LOOP"  condition 
condition  ::=  "WHILE"  expression 

|  "UNTIL"  expression 


ELSE  3 

%  Label  2  and  label  1  are  not  in  order 
%  The  labelled  statements  must  be  in 
%  order  of  increasing  size  of  the  labels. 


First  label  in  the  case_stat ement 
must  be  zero. 
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The  loop_head  has  two  forms  depending  on  whether  the  test  for 
the  condition  is  specified  in  the  loop_head  or  not.  The 
condition  has  itself  two  forms.  The  difference  between  each  form 
will  be  explained  below.  The  expression,  when  it  is  evaluated, 
must  yield  a  value  of  type  bits. 

5. 3. 4 . 2  Executable_statement_List 

The  list  of  statements  in  the  loop_statement  must  be 
executable_statement s.  Executable_statements  are  described  in 
Chapter  9. 

5. 3. 4 . 3  Loop_end 

l°op_end  : :=  "REPEAT" 

|  "REPEAT"  condition 

The  lcop_end  has  two  forms  depending  on  whether  the  test  for 
the  condition  is  or  is  not  specified  in  the  loop_end.  The 
loop_end  signals  the  end  of  the  loop_statement.  The  loop_end 
also  controls  the  number  of  times  the  statement  list  is  executed 
if  the  condition  is  in  it. 

Examples:  The  following  are  valid  loop_st atements . 

LOOP  UNTIL  (J>10)  &  (I<K)  %  Loop_st atement  tests  the  condition 

IF  B  %  at  the  beginning  of  each  iteration 

THEN  A[  I  ]  :=  0 
ELSE  A[J]  :=  0 
J  :=  J+1 
REPEAT 

LOOP 

SUM  :=  SUM+I 
I  :=  1+1 

REPEAT  WHILE  I<100 

If  the  condition  is  specified  in  the  loop_head,  then 
execution  proceeds  as  follows: 

1.  The  bit  expression  of  the  condition  is  evaluated.  If  the 
low  order  bit  of  the  result  is  one  and  the  while  form  .is 
used,  or  if  the  low  order  bit  of  the  result  is  zero  and  the 
until  form  is  used,  then  the  statement  list  is  executed. 
Otherwise  execution  is  transfered  to  the  first  statement 
following  the  loop_statement . 

2.  Once  the  list  cf  statements  is  executed,  step  1  (above)  is 
done  again. 

If  the  condition  is  specified  in  the  loop_end,  then  execution 
proceeds  as  follows: 

1.  The  list  of  statements  is  executed  once. 


%  Loo p_st atement  tests  the  condition 
%  at  the  end  of  an  iteration 
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2.  The  bit  expression  of  the  condition  is  evaluated.  If  the 
low  order  bit  of  the  result  is  one  and  the  while  form  is  used 
or  if  the  low  order  bit  of  the  result  is  zero  and  the  until 
form  is  used,  then  the  statement  list  is  executed  another 
time.  Otherwise  execution  is  transfered  to  the  first 
statement  following  the  loop_statement . 

3.  Once  the  list  of  statements  is  executed,  step  2  is  done 
again . 


A  semicolon  or  the  physical  end  of  the  source  program  record 
must  separate  the  loop_head  from  the  first  executable_state ment 
inside  a  loop_statement .  The  executable_statements  inside  a 
lcop_statement  must  be  terminated  by  either  semicolons  or  the 
physical  ends  of  source  program  records.  A  semicolon  or  the 
physical  end  of  a  source  program  record  may  appear,  optionally, 
between  the  last  executable_statement  in  a  loop_statement  and  the 
key  word  REPEAT. 

5. 3. 4.4  Exit_stat ement : 

e xit_statement  ::=  "EXIT" 

The  exit_st atement  is  only  used  inside  the  loop_statement . 
The  exit_statement  causes  the  unconditional  transfer  of  execution 
to  the  first  statement  that  follows  the  loop_statement . 

5.3.5  Group_statement 

group_statement  ::=  ”<<”  executable_statement_Elist  ,,»M 

A  group_statement  is  a  group  of  executable_sta tements  which 
are  to  be  considered  as  one  statement.  Group_statements  are 
useful  when  a  list  of  statements  is  one  of  the  alternatives  in  a 
selection  statement.  See  the  examples  below. 

Examples:  The  following  if_then_else_statement  contains  a  valid 
group_statement  following  the  keyword  THEN. 

IF  B 

THEN  <<  J : =4 

A : =J+I  >> 

ELSE  K : =5 

The  following  is  a  valid  group  statement. 

<<  IF  E  THEN  J: =  J+1 

ELSE  A:=  A+J+5 
K: =  K-A  >> 

The  following  is  an  invalid  group  statement. 


<<  J: =4 

IF  B  >> 


%  The  IF  B  by 

%  itself  is  not  an  executable 
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%  statement.  The  THEN 
%  part  and  the  ELSE  part  must 
%  appear  in  order  to  have  an 
%  executable=statement . 


A  semicolon  or  the  physical  end  of  a  source  program  record 
may  appear,  optionally,  between 

(1)  The  special  symbol  <<  and  the  first  executable_state ment 
in  the  group_statement. 

or  (2)  The  last  execut able_statement  in  a  group_state ment  and 
the  special_symbol  >>. 

The  executable_statements  inside  a  group_statement  are 
themselves  statements  and,  hence,  must  be  terminated  by  either 
semicolons  or  the  physical  ends  of  source  program  records.  (See 
Section  2.4). 
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CHAPTER  6 

Declaration  Statements 


6.  1  Introduction 

Declaration_statement s  provide  the  compiler  with  the  names 
and  the  types  of  the  quantities  used  in  the  source  program. 
Declaration_statements  also  provide  information  to  allocate 
locations  in  storage  for  variables,  arrays  and  records.  They 
also  provide  information  to  reference  non_local  variables. 
Declaration_statement s  do  not  produce  instructions  in  the  object 
program. 

6.2  Declaration_block 

OLGA  provides  for  three  kinds  of  subprograms:  procedures, 
functions  and  operators.  Subprograms  are  described  in  Chapter  7. 
Each  subprogram  contains  a  declaration_block.  Every  subprogram 
declares  in  its  declaration_block  all  the  variables  it  uses  and 
all  the  subprograms  it  calls. 

declaration_block  ::=  declare_statement 

declara tion_statement_Elist 
end_declare_statement 

Example:  The  example  below  is  an  example  of  a  subprogram  and  it 
shews  the  position  of  the  declara tion_block  relative  to  the 
other  statements  in  the  subprogram. 

PROCEDURE  MAIN 
DECLARE 


Declaration_statements  appear  here 


END 


DECLARE 


Executable_statement s  appear  here 


END  MAIN 


Each  subprogram  (ie:  procedure,  function  or 
declaration_block.  The  declarat ion_block  must 
beginning  of  the  subprogram.  (See 

Declaration_statements  can  only  appear 
decla rat ion_b locks.  Declaration's tatements  may 

order  in  the  declarat ion_block. 


operator)  has  a 
appear  at  the 
Chapter  7)  • 

inside  the 

appear  in  any 


Note  that  all  the  names  which  are  declared  in  a  subprogram 
are  known  only  in  the  executable_statement_List  of  that 
subprogram.  In  other  subprograms,  these  names  may  be  defined  to 
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represent  other  types  of  data  items.  The  rules  on  the  use  of 
identical  names  to  represent  different  data  items  in  different 
parts  of  a  program  are  given  in  Section  10.2. 

6.2.1  Declare  Statement 


declare_statement  ::=  "DECLARE” 

This  statement  signals  the  beginning  of  a  declaration_block. 

6.2.2  End_declare_statement 

end  declare  statement  ::=  "END"  "DECLARE" 


The  end_declare_statement  signals  the  end  of  the 
declaration_block. 

6.3  Variable  declarations 

All  variables  which  are  used  inside  a  subprogram  have  to  be 
declared  in  the  declar ation_bloc k  of  that  subprogram.  The 
declaration  of  variables  is  made  in  declaration_statement s. 

A  description  of  the  system  defined  types  used  in  variable 
declarations  appears  below.  Beside  the  system  defined  types, 
OLGA  allows  the  user  to  define  his  own  types  from  the  system 
defined  types.  These  types  are  described  in  Section  8.1. 


6.3.1  Simple  Variable  Declaration 


d eclar at ion_ statement 

type 
brief _type 


=  ident if ier_Seguence  ":"  type 
:=  brief_type 
:=  "INTEGER" 

|  "CHARACTER" 

|  "BITS" 

|  "POINTER"  "TO"  type 


Examples: 

I,  J,  K  :  INTEGER 
L  :  CHARACTER 
D,  F  :  BITS 


In  the  above  examples,  I,  J,  and  K  are  declared  to  be 
variables  of  type  integer;  L  is  a  variable  of  type  character;  and 
D  and  F  are  variables  of  type  bits.  The  brief_type  POINTER  TO 
type  will  b€  discussed  in  Section  6.3.4. 


6.3.2  Array  Declaration 


type  ::=  array_type 

array_type  ::=  "ARRAY"  "[ "  subscript_range  "]"  "OF"  brief _type 

subscript_range  ::=  integer  "TO"  integer 

I  integer 
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Examples: 

A,  B  :  ARRAY  [-10  TO  10]  OF  CHARACTER 
C  :  ARRAY  [  100  ]  OF  CHARACTER 
D  :  ARRAY  [  1  TO  10  ]  OF  BITS 

Two  things  must  be  specified  when  an  array  variable  is  declared: 

1.  The  range  of  values  which  the  subscript  may  acquire. 

2.  The  type  of  the  element  of  the  array. 

The  subscript  range  may  be  specified  in  two  forms: 

1.  integer  ”TO"  integer.  The  subscript  may  acquire  any 
integer  values  from  the  first  specified  integer  up  to  and 
including  the  second  specified  integer.  The  second  integer 
must  always  be  greater  than  or  equal  to  the  first  integer. 

2.  integer.  The  subscript  may  acquire  any  integer  value  from 
zero  up  to  and  including  the  specified  integer.  The  integer 
must  always  be  greater  than  or  equal  to  zero. 

6.3.3  Record  Declarations 

type  ::=  record_type 

record_type  ::=  ’’RECORD”  "[  "  f ield_declaration_Seguence  "  ]” 
f ield_declaration  ::=  identifier  type 

Example: 

A,  B,  C  :  RECORD  [FI: INTEGER ,  F2: CHAR ACTER ,  F3:BITS,  # 

F4 : ARRAY  [10]  OF  CHARACTER] 

In  the  example  above,  variables  A,  B,  and  C  are  declared  to 
be  records  which  are  made  up  of  the  following  fields: 

1.  FI  is  an  integer  field 

2.  F2  is  a  character  field 

3.  F3  is  a  bits  field 

4.  F4  is  an  array  [0  TO  10]  of  character  field. 

A  field  of  a  record  can  be  any  valid  OLGA  type,  including 
record  type. 

Associated  with  every  field  of  a  record  is  a  number.  This 
number,  called  the  offset,  is  the  number  of  memory  locations 
between  the  beginning  of  the  record  and  the  beginning  of  the 
field. 

Rule : 


An  identifier  may  be  declared  to  be  the  name  of  a  field  in 
more  than  one  record  declaration  in  a  declaration__block  if  all 
the  fields  having  that  name  have  the  same  offset  and  are  of  the 
same  type.  It  is  prohibited  to  use  the  same  identifier  to  denote 
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fields  of  records  declared  in  the  same  declaration_block  if  these 
fields  have  different  offsets  or  are  different  in  type. 


In  order  to  be  able  to  apply  this  rule,  the  method  to 
calculate  the  offset  of  a  field  is  given. 

Method  to  calculate  the  offset  of  a  field 

The  offset  of  the  first  field  in  a  record  is  always  zero. 
The  offset  of  a  field  is  given  by  the  sum  of  the  offset  of  the 
previous  field  and  the  number  of  memory  locations  occupied  by  the 
previous  field.  The  number  of  memory  locations  occupied  by  each 
type  of  field  is  given  below. 


1  .  Integer  = 

2.  Character 

3.  Pointer 

4.  Bits 

5.  Array 

6.  Record 


1 

1 

1 


Number  of  elements  in  the  array. 

Sum  of  the  offset  values  of  all  the  fields 
in  the  record  that  constitutes  the  field. 


Example : 

X  :  RECORD  [ A:BITS, B: EITS,C: INTEGER  ] 

Y  :  RECORD  [ A :INTEGER, B: EITS, D: BITS, C:INTEGER ] 


In  the  declaration  above,  the  two  declarations 
legal.  B  has  the  same  offset  (1)  and  denotes  the  same 
field,  bits.  However,  the  two  declarations  of  A  are 
The  reason  is  that  although  A  has  the  same  offset 
declarations  (0) ,  A  denotes  different  types  of  fields, 
declarations  of  C  are  also  illegal.  The  reason  is  that 
C  denote  the  same  type  of  field,  C  has  different  offset 
3)  in  the  two  declarations. 


of  B  are 
type  of 
illegal, 
in  both 
The  two 
although 
s  (2  and 


6.3.4  Pointer  Variable  Declaration 

type  ::=  brief_type 
brief _type  ::=  "POINTER"  "TO"  type 

|  "POINTER"  "TO"  "RECORD" 


Example : 

The  following  are  valid  declarations  of  pointer  variables. 

P:  POINTER  TO  INTEGER 
Q:  POINTER  TO  CHARACTER 
R:  POINTER  TO  BITS 

S:  POINTER  TO  ARRAY  [1  TO  10]  OF  CHARACTER 
T:  POINTER  TO  RECORD 
U  :  POINTER  TO  POINTER  TO  INTEGER 

A  pointer  variable  may  only  be  used  to  reference  the  type  of 
variable  that  appear  in  its  declaration.  For  example,  a  pointer 
variable  which  is  declared  to  point  to  integer  variables  cannot 
point  to  character  variables. 
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The  declaration  of  a  pointer  variable  must  include  the  type 
of  variable  which  is  referenced  by  the  pointer.  Note  that  the 
type  array_type  includes  the  array  bounds.  Therefore  a  pointer 
variable  must  not  point  to  an  array  whose  bounds  are  different 
from  the  bounds  of  the  array  declared  in  the  pointer  declaration 
even  if  the  array  has  the  same  number  of  elements. 

Example : 

P:  POINTER  TO  ARRAY  [  1  TO  1C ]  OF  CHARACTER 

A:  ARRAY  [ 1  TO  10]  OF  CHARACTER 

B:  ARRAY  [1  TO  100]  OF  CHARACTER 

P:=  REFER  [A]  %  Valid  assignment,  no  error  message 

%  is  produced 

P:=  REFER  [B]  %  Invalid  assignment,  error  message  is 

%  produced. 

A  pointer  variable  may  point  to  a  record  and  its  declaration 
does  not  have  to  include  the  declaration  of  the  types  of  the 
fields  of  the  record. 

Example ; 

P  :  POINTER  TO  RECORD[ FI : INTEGER,  # 

F2 : EITS  ]; 

Q  :  POINTER  TO  RECORD; 

In  the  above  declarations,  P  and  Q  are  equivalent.  P  and  Q 
may  both  point  to  record  structures.  A  pointer  variable  may  at 
different  stages  in  the  execution  point  to  records  with  different 
structures.  However,  the  programmer  is  discouraged  from  using 
the  same  pointer  variable  to  reference  records  with  different 
structures. 


6.3.5  Non_Iocal  Variables 

All  the  variables  declared  in  the  declaration_block  of  a 
subprogram  are  known  only  in  the  executable_statement_List  of 
this  subprogram  and  in  no  way  can  be  referenced  in  the 
executable_statement_List  of  another  subprogram  (except  by 
passing  them  as  arguments  to  that  subprogram) . 

All  the  variables  declared  in  the  declaration_bloc k  of  a 
data_block  are  known  by  all  the  subprograms  which  declare  these 
variables  to  be  non_local  variables  obtained  from  the  data_block. 
(Data_blocks  are  described  in  Section  7.7).  As  a  result, 
subprograms  may  reference  the  same  variables  by  the  use  of 
data_blocks. 

A  non_local  variable  in  a  subprogram  is  a  variable  which 
belongs  to  a  data_block  and  which  is  used  by  the  subprogram. 

6. 3. 5.1  Non  Local  Variable  Declaration 
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To  declare  a  non_local  variable  in  a  subprogram,  two  things 
must  be  specified: 

1.  The  type  of  the  variable 

2.  The  name  of  the  data_block  which  owns  the  variable. 

declaration_statement  ::=  ident if ier_Seguence  type 

“FROM”  identifier 

Example:  The  following  are  valid  declarations  of  non  local 

variables. 


I,  J,  K  :  INTEGER  FROM  SYMTAB 

A  :  ARRAY  [1  TO  10]  OF  CHARACTER  FROM  SYMTAB 
P  :  POINTER  TO  INTEGER  FROM  SYMTAB 

In  the  declaration  above,  I,  J  and  K  are  declared  to  be 
integers  from  the  data_block  SYMTAB;  A  is  an  array  [  1  TO  10]  of 
character  from  SYMTAB;  and  P  is  a  pointer  to  integer  from  SYMTAB. 

Variables  which  belong  to  a  data_block  will  be  declared  in 
the  data_block  in  the  same  way  as  variables  are  declared  in 
subprograms.  A  data_block  must  NOT  contain  declarations  of  non 
local  variables  obtained  from  other  data_blocks. 

Example: 

Data_block  which  Subprogram  which 

owns  the  variable  uses  the  variables 


DATA  SYMTAB 
DECLARE 


PROCEDURE  JOE 
DECLARE 


I, JrK: INTEGER 


END  DECLARE 
END  SYMTAB 


I,  J,  K:  INTEGER  FROM  SYMTAB 

END  DECLARE 


END  JOE 

In  the  example  above,  procedure  JOE  acguires  the  use  of 
variables.  I,  J,  and  K  from  the  data_block  SYMTAB. 

6.4  Subprogram  Declaration 

The  calling  properties  of  subprograms  which  are  called  by 
other  subprograms  must  be  declared  in  the  callers 
declaration_block.  These  properties  are  different  depending  upon 
the  type  of  the  called  subprogram. 
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6.4.1  Declaration  of  the  Calling  Properties  of  a  Procedure 

declaration_statement  : :=  identifier  "PROCEDURE" 

"[ "  type_Sequence  "  ]" 

|  identifier  "PROCEDURE" 

Example:  The  following  are  valid  declarations  of  the  calling 

properties  of  procedures. 

INITIL  :  PROCEDURE  [INTEGER,  POINTER  TO  INTEGER,  ARRAY  [10]  # 

OF  CHARACTER] 

OUT  :  PROCEDURE  [ARRAY  [80]  OF  CHARACTER] 

JOE  :  PROCEDURE 

To  declare  the  calling  properties  of  a  procedure,  two  things  must 
be  specified: 

1.  The  name  of  the  procedure 

2.  The  types  of  the  arguments  expected  by  the  procedure,  A 
procedure  may  be  parameterless  in  which  case  the  list  of  the 
types  of  the  parameters  must  be  omitted. 


The  types  of  the  parameters  of  a  procedure  may  be  any  valid 
OLGA  type.  A  parameter  must  not  be  the  name  of  a  procedure,  a 
function  or  an  operator. 

6.4.2  Declaration  of  the  Calling  Properties  of  a  Function 

declaration_statement : : =  identifier  ":"  "FUNCTION” 

"[ "  type_Sequence  "]"  "RETURNS" 
brief_ty pe 

Examples :  The  following  are  valid  declarations  of  the  calling 

properties  of  functions 

RANDOM  :  FUNCTION  [INTEGER]  RETURNS  INTEGER 

SCAN  :  FUNCTION  [ARRAY  [1  TO  80 ]  OF  CHARACTER]  # 

RETURNS  INTEGER 

HUE  :  FUNCTION  RETURNS  POINTER  TO  ARRAY  [80]  OF  CHARACTER 

To  declare  the  calling  properties  of  a  function,  three  things 
must  be  specified: 

1  .  The  name  of  the  function 

2.  The  types  of  the  arguments  expected  by  the  function.  A 
function  may  be  parameterless  in  which  case  the  list  of  the 
types  of  the  parameters  must  be  omitted. 

3.  The  type  of  the  value  returned  by  the  function.  A 
function  will  always  return  a  value. 

The  types  of  the  parameters  of  a  function  may  be  any  valid 
OLGA  type,  A  parameter  must  not  be  the  name  of  a  procedure, 
function  or  operator. 

The  type  of  the  value  returned  by  a  function  must  be  a 
brief_type,  i.e.  an  integer,  a  character,  a  bits,  or  a  pointer 
type.  The  type  of  the  value  returned  by  a  function  must  not  be 
array  type,  or  record  type. 
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6.4.3  Declaration  of  the  Calling  Properties  of  Operator 
Subprograms 

A  programmer  defined  operator  is  a  subprogram  which  returns  a 
single  value  to  the  calling  program.  It  differs  from  a  function 
only  in  the  manner  in  which  it  is  employed  (or  called)  in  an 
expression. 

There  are  two  kinds  of  programmer  defined  operators: 

1.  Monadic  Operators  -  A  Monadic  operator  operates  on  one 
operand . 

2.  Dyadic  Operators  -  A  Dyadic  operator  operates  on  two 
operands. 

6. 4. 3.1  Declaration  of  the  Calling  Properties  of  Programmer  Defined 
Monadic  Operators 

declaration_st atement  ::=  identifier  ":"  "OPERATOR" 

"["  type  "]" 

"RETURNS"  brief _type 

Examples:  The  following  are  valid  declarations  of  the  calling 

properties  of  programmer  defined  Monadic  operators. 

MINUS  :  OPERATOR  [INTEGER]  RETURNS  INTEGER 
ROTATE  :  OPERATOR  [BITS]  RETURNS  BITS 

To  declare  the  calling  properties  of  programmer  defined  Monadic 
operators,  three  things  must  be  specified: 

1.  The  name  of  the  monadic  operator 

2.  The  type  of  the  operand  expected  by  the  monadic  operator 

3.  The  type  of  value  returned  by  the  monadic  operator. 

6. 4. 3. 2  Declaration  of  the  Calling  Properties  of  Programmer  Defined 
Dyadic  Operators. 

declaration_statement  ::=  identifier  ":"  "OPERATOR" 

»["  type  "," 
type  " ]" 

"RETURNS"  brief _type 

Examples:  The  following  are  valid  declarations  of  the  calling 

properties  of  programmer  defined  Dyadic  operators. 

MULT  :  OPERATOR  [ INTEGER , INTEGER  ]  RETURNS  INTEGER 
SWAP  :  OPERATOR  [ I NTEGER, INTEGER  ]  RETURNS  BITS 

To  declare  the  calling  properties  of  programmer  defined  Dyadic 
operators,  three  things  must  be  specified: 

1.  The  name  of  the  dyadic  operator. 

2.  The  types  of  the  two  operands  expected  by  the  dyadic 
operator. 

3.  The  type  of  value  returned  by  the  dyadic  operator. 
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The  types  of  the  operands  of  an  operator  of  either  kind  may 
be  any  valid  OLGA  type. 

The  type  of  the  value  returned  by  an  operator  must  be  a 
brief_typer  an  integer,  a  character,  a  bits  or  a  pointer.  The 
type  of  the  value  returned  by  an  operator  must  not  be  array  type 
or  record  type. 


Below  is  a  table  which  summarizes  declarations  of  the  calling 
properties  of  programmer  defined  subprograms. 


Subprogram 

Procedure 

Function 

Operator 
(Monadic  + 


Type  of  the  arguments 
or  the  operands 

type 

type 

type 

Dyadic) 


Type  of  the  result 
returned 

None 

br ief_type 
brief_type 


6.5  Required  Declarations 


A  subprogram  must  declare  in  its  declaration  block  all  the 
variables  that  it  uses  and  all  the  subprograms  that  it  calls 
except 

(a)  A  subprogram  must  not  declare  the  procedures,  operators  and 
functions  which  are  provided  by  OLGA. 

(b)  A  subprogram  declares  in  its  heading  the  type  of  its 
parameters  and  the  type  of  the  returned  result  (if  any).  See 
Chapter  7. 
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CHAPTER  7 

Subprograms  and  Data  blocks 

7.1  Introduction 

OLGA  provides  for  three  kinds  of  subprograms:  procedures, 
functions  and  operators.  Functions  and  operators  differ  from 
procedures  in  that  they  always  return  a  single  value  to  the 
calling  program.  Operators  differ  from  functions  in  the  way  they 
are  employed  (or  called)  in  expressions.  An  operator  is  called 
by  writing  the  name  of  the  operator  and  its  operand  (operands)  in 
a  standard  expression.  A  function  is  called  by  writing  the  name 
of  the  function  and  an  argument  list  in  a  standard  expression.  A 
procedure  must  be  called  by  a  special  statement:  The 

Procedure_invocation_statement. 

Procedures,  functions  and  operators  are  of  two  types: 

1.  System  defined.  The  programmer  may  use  them  directly. 

Operators  provided  by  OLGA  are  described  in  Section  3.5. 

Procedures  and  Functions  provided  by  OLGA  are  described  in 
Chapter  9. 

2.  Programmer  defined.  This  chapter  describes  how  the 

programmer  defines  and  uses  subprograms. 

A  data_block  is  a  named  collection  of  variables.  Data_blocks 
allow  one  cr  more  subprograms  to  reference  a  common  set  of 
variables.  In  this  way,  subprograms  may  share  variables  by  using 
data_blocks. 

7.2  Naming  Procedures,  Functions,  Operators  and  Data_blocks. 

The  name  of  a  procedure,  a  function,  an  operator  or  a  data 
block,  defined  by  the  programmer  must  be  an  identifier. 

Identifiers  are  described  in  Section  3.2.1. 

7.3  Functions 

Functions  are  subprograms  which  always  return  a  single  value 
to  the  calling  program.  A  function  subprogram  may  acquire  values 
from  the  calling  program  and  may  also  return  values  to  the 
calling  program  by  the  use  of  the  arguments.  To  use  a  programmer 
defined  function,  it  is  necessary  to: 

1.  Define  the  function,  ie:  Specify  what  calculations  are  to 
be  performed 

2.  Declare  the  calling  properties  of  the  function  in  the 
declaration_block  of  the  calling  subprogram.  (See  Section 
6.4.2)  . 

3.  Call  the  function  where  required  in  the  calling 
subprogram . 

7.3.1  Defining  Functions 

There  are  four  steps  in  the  definition  of  a  function  in  OLGA: 
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1 .  The  function  must  be  assigned  a  unique  name  by  which  it 
may  be  called  (see  the  section  "Naming  Procedures,  Functions, 
Operators  and  Data  blocks")  . 

2.  The  arguments  of  the  function  and  their  types  must  be 
stated.  If  the  function  does  not  have  any  arguments,  then 
this  step  must  be  omitted. 

3.  The  declar ation_block  of  the  function  must  be  stated. 

4.  The  procedure  for  evaluating  the  function  must  be  stated. 


function  ::=  f unction_heading  declaration_block 

executable_statement_List 

end_statement 

f unction_heading  : :=  optional_reentrancy  "FUNCTION"  identifier 

"[ "  argument_declaration  Sequence  "]" 
"RETURNS"  br ief_type 
|  optional_reentrancy  "FUNCTION" 
identifier  "RETURNS" 
brief_type 

argument_declaration  ::=  identifier  ":"  type 

cptional_reentrancy  : :=  "REENTRANT" 

| empty 

end_statement  ::=  "END"  identifier 
Example: 

The  following  is  a  valid  function  definition. 

FUNCTION  RANDOM  [X:  INTEGER]  RETURNS  INTEGER 
DECI ARE 

.  Declaration  statements  appear  here 

END  DECIARE 

.  Executable  statements  appear  here 

END  RANDOM 

Note  that  the  name  of  the  function  must  appear  in  the 
End_state ment  of  the  function.  Reentrant  functions  will  be 
described  in  Section  7.8. 

The  types  of  the  arguments  in  a  function  reference  may  be 
integer,  character,  bits,  pointer  type,  any  valid  OLGA  type.  An 
argument  must  not  be  the  name  of  a  procedure,  a  function  or  an 
operator. 

The  arguments  of  the  Function  subprogram  may  be  considered  to 
be  dummy  variable  names.  The  values  that  are  associated  with 
these  names  are  initialized  at  the  time  of  each  execution  by  the 
values  of  the  actual  arguments  supplied  in  the  instance  of  the 
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function  call.  If  the  values  associated  with  the  dummy  variables 
are  subsequently  changed  during  execution  of  this  invocation  of 
the  function,  then  the  values  of  the  actual  arguments  in  the 
calling  program  will  change  correspondingly  unless  the  actual 
arguments  were  constants. 

The  function  subprogram  will  return  control  to  the  calling 
program  by  executing  a  return_statement .  The  return_statement , 
(See  7.6),  also  establishes  the  value  to  be  returned. 

7.3.2  Calling  Functions. 

When  the  name  of  a  function  appears  in  any  OLGA  expression 
this  calls  the  function.  Thus,  the  appearance  of  a  function  with 
its  arguments  (in  square  brackets)  causes  the  computations 
indicated  by  the  function  definition.  The  resulting  quantity 
replaces  the  function  reference  in  the  expression  and  assumes  the 
type  of  the  result  of  the  function. 

Example:  The  following  example  illustrates  one  way  in  which  a 

function  may  be  used  in  a  program. 

Calling  program  FUNCTION  CALC  [ A : INT EGER ,  # 

DECLARE  X :INT  EGER  ]  # 

.  RETURNS  # 

.  INTEGER 

• 

ANS,X,Y: INTEGER  DECLARE 


CALC: FUNCTION[ INTEGER, INTEGER  ]  #  END  DECLARE 

RETURNS  INTEGER 


END  DECLARE 

.  RETURN  A+X*2 


ANS  :=  3+CALC[ X , Y ] 

•  • 

.  END  CALC 

In  this  example,  the  values  of  X  and  Y  are  used  in  the 
function  subprogram  as  the  values  of  A  and  X  respectively.  The 
value  of  CALC  is  computed  and  this  value  is  returned  to  the 
calling  program  where  the  value  of  ANS  is  computed.  Note  that 
the  value  of  X  in  the  calling  program  is  changed  if  a  new  value 
is  assigned  to  A  in  the  function  subprogram. 

7. 4  Operators . 

Operators  are  subprograms  which  always  return  a  single  value 
to  the  calling  program.  Operands  are  passed  to  operators  by  the 
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calling  programs.  To  use  a  programmer  defined  operator,  it  is 
necessary  to: 

1.  Define  the  operator,  i.e.r  specify  what  calculations  are 
to  be  performed 

2.  Declare  the  calling  properties  of  the  operator  in  the 
declaration_block  of  the  calling  subprogram.  (See  Section 
6.4.3)  . 

3.  Call  the  operator  where  required  in  the  calling 

subprogram. 

7.4.1  Defining  Operators. 

There  are  four  steps  in  the  definition  of  an  operator  in 
OLGA: 

1.  The  operator  must  be  assigned  a  unique  name  by  which  it 
may  be  called  (see  the  section  "Naming  Procedures,  Function, 
Operators  and  Data  blocks"). 

2.  The  operands  of  the  operator  and  their  types  must  be 
stated.  An  operator  must  have  either  one  or  two  operands. 

3.  The  declaration_block  of  the  operator  must  be  stated. 

4.  The  procedure  for  evaluating  the  operation  must  be  stated. 

operator  ::=  operator_heading  declaration_block 

executable_statement_List 

end_statement 

operator_heading  ::=  optional_reentrancy  "OPERATOR"  identifier  "[  " 

identifier  ":"  type 
identifier  type  " 

"RETURNS"  brief_type 

|  optional_reent rancy  "OPERATOR"  identifier  "[  " 
identifier  ":"  type  "  ]" 

"RETURNS"  brief_type 

Example 

The  following  is  a  valid  operator  definition. 


OPERATOR  MUL  [ A:I NTEGER,  X :INTEGER ]  RETURNS  INTEGER 
DECLARE 

.  Declaration  statements  appear  here 

END  DECLARE 


.  Executable  statements  appear  here 


END  MUL 

Note  that  the  name  of  the  operator  must  appear  in  the  End 
statement  of  the  operator  subprogram.  The  types  of  the  operands 
in  an  operator  reference  may  be  any  valid  OLGA  type.  Reentrant 
operators  will  be  described  in  Section  7.8. 
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The  operands  (arguments)  of  the  operator  subprogram  may  be 
considered  to  be  dummy  variable  names.  The  values  that  are 
associated  with  these  names  are  initialized  at  the  time  of  each 
execution  by  the  values  of  the  actual  operands  supplied  in  the 
instance  of  the  operator  call.  Changing  the  values  associated 
with  the  dummy  variables  during  execution  of  the  invocation  of 
the  operator  will  NOT  change  the  values  of  the  actual  operands  in 
the  calling  program. 

The  operator  subprogram  will  return  control  to  the  calling 
program  by  executing  a  return  statement.  The  return_statement , 
(See  7.6),  also  establishes  tHe  value  to  be  returned. 


7.4.2  Calling  Operators. 

When  the  name  of  an  operator  appears  in  any  OLGA  expression, 
this,  effectively  calls  the  operator.  Thus  the  appearance  of  an 
operator  with  operands  causes  the  computations  indicated  by  the 
operator  definition.  The  resulting  guantity  replaces  the 
operator  and  its  operands  in  the  expression  and  assumes  the  type 
of  the  result  of  the  operator. 


Example: 


The  following  example  illus 
operator  may  be  used  in  a  program. 

Calling  program 
DECLARE 

t 

ANS,X,Y: INTEGER 


trates  one  way  in  which  an 


OPERATOR  MUL[  AlINTEGER,  # 

X:I  NTEGER  ]# 
RETURNS  # 
INTEGER 

DECLARE 


MUL:OPERATOR[ INTEGER, INTEGER ]#  END  DECLARE 

'  RETURNS  INTEGER 

•  • 

END  DECLARE 


AN S : =20+X  MUL  Y 


RETURN  A*X 


•  • 

.  END  MUL 

In  this  example,  the  values  of  X  and  Y  are  used  in  the 
Operator  subprogram  as  the  values  of  A  and  X  respectively.  The 
value  of  the  operation  MUL  is  calculated  and  this  value  is 
returned  to  the  calling  program  where  the  value  of  ANS  is 
computed.  Note  that  the  value  of  X  in  the  calling  program  is  not 
changed  if  a  new  value  is  assigned  to  A  in  the  operator 
subprogram. 
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7.5  Procedures 

Procedures  are  subprograms  which  may  return  values  to  the 
calling  program  only  by  the  use  of  arguments  or  non_local 
variables  from  data  blocks.  Procedures  may  also  acguire  values 
from  the  calling  program  by  the  use  of  the  arguments  and 
ncn_lccal  variables  from  data_blocks.  To  use  a  programmer 
defined  procedure,  it  is  necessary  to: 

1.  Define  the  procedure,  ie:  Specify  what  calculations  are  to 
be  performed. 

2.  Declare  the  calling  properties  of  the  procedure  in  the 
declaration_block  of  the  calling  subprogram.  (See  Section 

6. 4.  1)  . 

3.  Call  the  procedure  where  reguired  in  the  calling 
subprogram . 


Rule : 


Every  program  must  have  as  one  of  its  procedures  a  procedure 
called  MAIN.  When  a  program  is  executed,  control  originates  at 
the  first  executable_stat ement  of  MAIN. 

7.5.1  Defining  Procedures 

There  are  four  steps  in  the  definition  of  a  procedure  in 
01GA: 

1.  The  procedure  must  be  assigned  a  unique  name  by  which  it 
may  be  called.  (See  the  section  "Naming  Procedures, 
Functions,  Operators  and  Data  blocks”) . 

2.  The  arguments  of  the  procedure  and  their  types  must  be 
stated.  If  the  procedure  does  not  have  any  arguments,  then 
this  step  may  be  omitted. 

3.  The  declaration_block  of  the  procedure  must  be  stated. 

4.  The  calculations  performed  by  the  procedure  must  be 
stated. 

procedure  ::=  procedure_heading  declaration_block 

executable_statement_List 
end_stateme  nt 

procedure_heading  ::=  opt ional_reentrancy  "PROCEDURE"  identifier 

"["  argument_declaration_Seguence  "  ]" 

|  optional_reen trancy  "PROCEDURE"  identifier 


Example: 


The  following  is  a  valid  procedure  definition. 

PROCEDURE  INTGRT  [A:  INTEGER,  P:  POINTER  TO  ARRAY  [100]  # 

OF  CHARACTER  ] 

DECLARE 

• 

.  Declaration_statement s  appear  here 

END  DECLARE 

.  Executable_state ments  appear  here 


END  INTGRT 

Note  that  the  name  of  the  procedure  must  appear  in  the  End 
Statement  of  the  procedure.  The  types  of  the  arguments  in  a 
procedure  reference  may  be  integer,  character,  bits,  pointer 
type,  array  type,  or  record  type.  An  argument  must  not  be  a 
procedure,  a  function,  or  an  operator.  Reentrant  procedures  will 
be  described  in  Sect.  7.8. 

The  arguments  of  the  procedure  subprogram  may  be  considered 
to  be  dummy  variable  names.  The  values  that  are  associated  with 
these  names  are  initialized  at  the  time  of  each  execution  by  the 
values  of  the  actual  arguments  supplied  in  the  instance  of  the 
procedure  call.  If  the  values  associated  with  the  dummy 
variables  are  subsequently  changed  during  execution  of  this 
invocation  of  the  procedure,  then  the  values  of  the  actual 
arguments  in  the  calling  program  will  change  correspondingly 
unless  the  actual  arguments  were  constants. 

The  procedure  subprogram  will  return  control  to  the  calling 
program  by  executing  a  return_statement .  The  procedure 

subprogram  is  called  by  a  special  statement:  the 

Procedure_invocation_statement. 

7.5.2  Procedure_invocation_statemen t 

executable_statement  ::=  identifier 

|  identifier  expression_Seguence  "  ] 

The  procedure_in vocation_sta tement  is  used  only  to  call  a 
procedure  subprogram. 

Examples:  The  following  are  valid  procedure_in voca tion 

statements. 

OUT 

I NTL  [X,  5,  P,  4,  3] 

The  procedure_in vocation_statement  transfers  control  to  the 
procedure  subprogram  and  replaces  the  dummy  variables  with  the 
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value  of  the  actual  arguments  that  appear  in  the  procedure 
i n voc a tion_ statement. 

The  arguments  in  a  procedure_invocation_statement  must  agree 
in  number,  order,  and  type  with  the  corresponding  arguments  in 
the  procedure  subprogram. 

7.6  Return_statement 

return_statement  : :=  "RETURN" 

|  "RETURN"  expression 

This  is  the  normal  exit  from  a  subprogram.  The  Return 
statement  signifies  a  logical  conclusion  of  the  computation  and 
returns  any  value  computed  and  control  to  the  calling  program. 

All  subprograms  except  the  MAIN  procedure  must  contain  at 
least  one  Return.  If  a  subprogram  does  not  have  a  return 
statement,  then  control  from  that  subprogram  will  return  to  the 
calling  program  once  the  last  execut able_statement  of  the 
subprogram  has  been  executed.  There  may  be  more  than  one 
return_st atement  in  each  subprogram. 

7.7  Data_blocks. 

A  data_block  is  a  named  collection  of  variables.  Data_blocks 
allow  one  or  more  subprograms  to  refer  to  a  common  set  of 
variables.  In  this  way,  subprograms  may  share  variables  by  using 
data_blocks. 

Note  that  only  the  variables  of  data_blocks  may  be  shared. 
The  variables  of  a  subprogram  cannot  be  shared  by  another 
subprogram  in  this  manner.  To  use  the  variables  of  a  data_block, 
it  is  necessary  to: 

1.  Define  the  data^block,  ie:  Specify  the  variables  in  the 
Data  block. 

2.  Declare  the  properties  of  the  variables  in  the 
declaration_blocks  of  the  subprograms  which  uses  them. 
Declarations  of  non_local  variables  are  described  in  6.3.5. 

3.  Reference  the  variables  where  reguired  in  the  program. 

7.7.1  Defining  Data_blocks. 

There  are  two  steps  in  the  definition  of  a  data_block  in 
OLGA: 

1.  The  data_block  must  be  assigned  a  unigue  name  by  which  it 
may  be  referenced. 

2.  The  declaration_blcck  of  the  data_block  must  be  stated. 

d ata_block  ::=  data_b lock_heading  declaration_block 

end_sta te  ment 

d ata_block_heading  ::=  "DATA"  identifier 

Example:  The  following  is  a  valid  data_block  definition. 
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DATA  SYMTAB 
DECLARE 

I,J,K  :  INTEGER 

A  :  ARRAY  [1  TO  80]  OF  CHARACTER 
END  DECLARE 
END  SYMTAB 

Variables  which  are  shared  by  subprograms  are  declared  in  the 
declar ation_block  of  a  data_block.  A  data_block  must  NOT  declare 
variables  of  other  data_blocks. 

Rule: 


The  definition  of  a  data_block  must  precede  the  definitions 
of  all  the  subprograms  which  use  its  variables.  See  Chapter  10 
for  the  arrangements  of  subprograms  and  data_blocks  in  a  program. 

7.7.2  Osing  Data  blocks 

Example :  The  following  example  illustrates  the  use  of  a  data 

block.  Data  blocks  are  used  to  share  variables  among 
subprograms. 

Data  block  defined 
DATA  SYMTAB 
DECLARE 

•  • 

•  • 

•  • 

I,J,K  :  INTEGER  I,J,K  :  INTEGER  FROM  SYMTAB 


Subprograms 
PROCEDURE  JOE 
DECLARE 


END  DECLARE 
END  SYMTAB 


END  DECLARE 

END  JOE 


PROCEDURE  BOO 
DECLARE 


I  :  INTEGER  FROM  SYMTAB 

END  DECLARE 
END  BOO 

In  the  example  above.  Procedure  JOE  acquires  the  variables 
I,J,K  from  the  data_block  SYMTAB;  Procedure  BOO  acquires  the 
variable  I  from  SYMTAB.  Note  that  Procedure  BOO  may  not 
reference  J  or  K.  The  value  of  variable  I  is  changed  if  a  new 
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value  is  assigned  to  I  in  procedure  BOO.  Procedure  JOE  can 
change  the  values  of  variables  I,J,  and  K. 


7.8  Reentrant  Subprograms 

A  subprogram  that  is  defined  with  the  keyword  "REENTRANT"  in 
its  heading  may  call  itself  directly  or  indirectly  through  other 
subprograms.  A  subprogram  that  is  not  defined  with  the  keyword 
"REENTRANT"  may  not  call  itself  either  directly  or  indirectly. 

A  reentrant  subprogram  has  separate  data  areas  allocated  for 
its  local  variables  and  parameters  for  each  of  its  invocations. 
As  a  result,  when  a  reentrant  subprogram  calls  itself,  the  later 
invocation  does  not  destroy  the  local  variable  and  parameter 
values  of  the  earlier  invocations.  When  the  reentrant  subprogram 
returns  control  to  the  earlier  invocation,  the  local  variable  and 
parameter  values  of  the  invocation  that  has  terminated  are  lost, 
but  those  of  the  earlier  invocation  are  not  lost. 

Implementation  Restriction 

Local  records  cannot  be  declared  in  a  reentrant  subprogram 
(but  non-local  records  can  be  declared) .  To  obtain  the  same 
effect  with  local  records  as  that  obtained  for  other  kinds  of 
variables,  the  user  must  perform  dynamic  allocation  for  these 
records  using  the  functions  described  in  Section  9.5. 
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Chapter  8 

Types,  literals ,  and  Modules 

8 . 1  Types 

OLGA  allows  the  user  to  define  his  own  data  types.  In  a  type 
definition,  a  name  is  given  to  a  data  type  built  from  system 
defined  data  types  or  from  previously  defined  user  data  types. 
Once  a  type  has  been  defined  in  a  type  definition,  it  can  be  used 
wherever  a  system  defined  type  is  used.  For  example,  a  user 
defined  type  can  be  used  in  variable  declarations,  procedures, 
functions,  and  operator  declarations,  type  definitions  and  as 
arguments  to  the  pseudo_f unction  ALLOC  (see  Sect.  9.5). 


A  user  defined  type  must  be  defined  in  a  ty pe_de f inition 
prior  to  its  use. 


t ype_def inition  ::=  "TYPE"  identifier  "="  type 
type  ::=  identifier 


(See  Section  6.3  for  a  description  of  system  defined  types.) 


Type_def initions  appear  outside  of  procedures,  functions, 
operators,  and  data  blocks.  (See  Chapter  10). 

Examples: 

The  following  illustrate  some  uses  of  types. 

TYPE  ST ACK=R  ECCRD[ PTR : I NT EGER ,  # 

LIST  :ARR AY[  1 5]OF  INTEGER] 

PROCEDURE  MAIN 
DECLARE 

S  1, S2:STACK 

P:POINTER  TO  STACK 
END  DECLARE 


SI. PTR  :=  0  %SET  STACKI's  POINTER 

P  :=  ALLOC[ STACK] 

3P.LIST[0]  :=  0  %PUT  SOMETHING  IN  STACK 
END  MAIN 

The  type  name  may  not  appear  in  its  own  definition.  However, 
this  dees  not  restrict  the  programmer  from  defining  types  which 
are  used  to  declare  the  nodes  of  linked  lists.  The  following 
illustrate  the  use  of  types  to  define  a  type  of  node  of  a  linked 
list. 


TYPE  NODE  =  RECORD[  VALUE: INTEGER, # 

L SON : POINTER  TO  RECORD,# 

RSON : POINTER  TO  RECORD] 

L SON  and  RSON  can  point  to  other  instances  of  type  NODE. 

User  defined  types  are  implemented  using  the  literal 
construct  described  in  the  next  section.  As  a  result,  if  a  type 


54 


name  appears  in  its  own  definition,  the  'LITERAL  STACK  OVERFLOW 
error  will  occur. 


8.2  Literals 

Literals  are  used  when  textual  substitution  is  to  be 
performed  in  a  source  program.  In  a  literal  definition,  a  name 
is  assigned  to  a  string  of  characters.  Except  where  otherwise 
noted,  the  occurrence  of  this  name  in  a  source  program  will  cause 
the  replacement  of  this  name  by  the  character  string  appearing  in 
the  literal  definition.  Literals  can  be  used  to  name  constants 
or  to  reduce  the  amount  of  writing  reguired  to  declare  various 
quantities  in  a  program. 

A  literal  must  be  defined  in  a  literal_def init ion  prior  to 
its  use. 

1 iteral_def inition  ::=  "LITERAL"  identifier  "="  character_str ing 

(See  section  4.2  for  a  description  of  character  strings). 

Literal_def initions  appear  outside  of  procedures,  functions, 
operators,  and  data_blocks.  (See  Chapter  10). 

Examples : 

The  following  illustrates  some  uses  of  literals. 

LITERAL  MEMORY_SZ  =  '4096' 

LITERAL  I NI_DCL  =  ' INI  :PROCEDUR E[  INTEGER ] ' 

PROCEDURE  MAIN 
DECLARE 

J: I NTEGE  R 
INI_DCL 

END  DECLARE 

J:=MEMORY_SZ 
END  MAIN 

In  procedure  MAIN,  the  appearance  of  INI_DCL  causes  its 
replacement  by  the  character  string  appearing  in  the  literal 
definition  of  INI_DCL.  As  a  result  the  procedure  INI  is  declared 
in  MAIN.  The  appearance  of  MEMORY_SZ  in  the  replacement 
statement  causes  its  replacement  by  the  integer  constant  4096. 

A  literal  can  be  used  in  the  definition  of  another  literal. 
The  maximum  literal  nesting  level  allowed  by  the  compiler  is 
four. 


Literals  are  not  replaced  by  their  character  strings  if  they 
occur  in  one  of  two  places: 

1)  Inside  comments  and  character  strings. 
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2)  In  IMPORT  and  in  EXPORT  clauses  of  modules,  (See  the  next 
section  for  description  of  MODULES) . 


8 . 3  Modules 

A  module  is  used  to  enclose  related  abstractions  and  to 
isolate  these  abstractions  from  the  environment  outside  the 
module.  A  module  may  contain  procedure  definitions,  function 
definitions,  operator  definitions,  data_block  definitions, 
literal  definitions,  and  type  definitions.  However,  a  module  may 
net  contain  another  module. 

Modules  have  the  following  properties: 

1)  Abstractions  defined  in  a  module  can  be  called  from  the 
environment  outside  the  module  only  if  the  module 
explicitly  exports  them. 

2)  Abstractions  defined  outside  a  module  can  be  called  from 
inside  only  if  the  module  explicitly  imports  them. 

Hence,  it  is  seen  that  a  module  in  effect  screens  part  of  the 
complexity  that  it  presents  to  the  outside  environment;  only  some 
of  its  abstractions  are  visible  outside.  In  a  similar  way,  a 
module  screens  part  of  the  complexity  of  the  outside  as  seen  by 
its  abstractions;  it  only  imports  some  of  the  abstractions 
defined  outside. 


8.3.1  Module  Definitions: 

module  ::=  module_heading 

abstr actio n_List 
end_statement 

abstraction  ::=  procedure  |  operator 

|  function  |  data_block 
|  liter al_def initio n 
| type_def inition 

module_heading  ::=  "MODULE"  identifier 

opt ional-import_clause 
optional_export_clause 

optional_import_clause  ::=  "IMPORTS"  identif ier_Sequence 

| empty 

optional_export_clause  ::=  "EXPORTS"  ident if ier_Sequence 

(empty 

A  module  must  declare  in  the  import  clause  of  its  heading  the 
names  of  all  abstractions  defined  outside  the  module  which  are  to 
be  visible  inside.  Also,  a  module  must  declare  in  the  export 
clause  of  its  heading  the  names  of  all  abstractions  defined  in 
the  module  which  are  to  be  visible  outside.  All  abstractions 
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defined  inside  a  module  and  not  exported  outside  are  not  visible 
outside  the  module. 

Example :  The  following  is  used  to  illustrate  the  visibility  of 

abstractions  inside  and  outside  modules. 

MODULE  SYM_TAB  EXPORTS  INSERT,  DELETE 

• 

%  INSERT  AND  DELETE 
%  ARE  PROCEDURES  DEFINED 
%  HERE 

• 

END  S YM_T AB 

MODULE  SCANNER  IMPORTS  INSERT  EXPORTS  TOKEN  BUF 

• 

%  TOKEN_BUF  IS  A  DAT A_BLOCK 
%  DEFINED  HERE 

END  SCANNER 

Inside  SYM_TAB,  the  following  abstractions  are  visible 

1)  All  abstractions  defined  in  SYM_TAB 

Inside  SCANNER,  the  following  abstractions  are  visible 

1)  All  abstractions  defined  in  SCANNER 

2)  INSERT  obtained  from  SYM  TAB 


Outside  SCANNER  and  SYMTAB,  the  following  abstractions  of 
SCANNER  and  SYMTAB  are  visible 

1)  TO  KEN_BUF 

2)  INSERT 

3)  DELETE 

It  should  be  noted  that  names  of  literals  appearing  in  import 
and  export  clauses  are  not  replaced  by  the  character  strings 
appearing  in  their  definitions.  Instead  the  names  of  the 
literals  are  themselves  imported  and  exported  in  the  same  way  as 
the  names  of  any  other  kind  of  abstraction  appearing  in  these 
clauses. 

Any  literals,  types  or  data  blocks  which  are  to  be  imported 
must  be  defined  before  the  module  is  defined.  This  does  not 
apply  to  procedures,  functions  and  operators. 


,57 


CHAPTER  9 

System  defined  Procedures  and  Functions 
9 .  1  Introduction 

This  chapter  describes  the  procedures  and  the  functions  which 
are  provided  by  OLGA.  The  operators  which  are  defined  by  OLGA 
are  described  in  section  3.5.  Procedures,  functions  and 
operators  which  are  defined  by  OLGA  must  not  be  declared  by  the 
programmer. 

The  procedures  and  the  functions  which  are  defined  by  OLGA 
serve  five  purposes: 

1 .  Type  Conversion  -  To  convert  a  value  from  one  type  to 
another  type. 

2.  Input/Output  -  To  read/print  values  during  execution. 

3.  Address  -  To  obtain  pointer  values. 

4.  Allocation  and  Deallocation  -  To  allocate  and  deallocate 
memory  locations  during  execution. 

5.  Shift  -  To  shift  the  bits  of  a  bits  value  by  one  place. 

9.2  Type  Conversion  Functions 


CVCI,  Convert  Character  to  Integer  Function 


This  function  has  the  following  implicit  declaration: 
CVCI  :  FUNCTION  [CHARACTER]  RETURNS  INTEGER 


The  convert  Character  to  Integer  function 
argument  of  type  Character.  It  returns 
program  an  integer  which  is  the  ASCII  code 
the  character.  (See  Appendix  E) 


requires  a  single 
to  the  calling 
representation  of 


Example : 


CVCI  [  *  A  *  ]  returns  a  value  of  65  (octal  =  101) 
CVIC  Convert  Integer  to  Character  Function 


This  function  has  the  following  implicit  declaration: 
CVIC  :  FUNCTION  [INTEGER]  RETURNS  CHARACTER 


The  Convert  Integer  to  Character  function  requires  a  single 
argument  of  type  integer.  It  returns  to  the  calling  program 
a  character  whose  ASCII  code  representation  is  the  integer 
value . 

These  functions  are  useful  to  the  programmer  who  wants  to 
convert  integer  to  character  strings  and  character  strings  to 
integer. 


Example:  A  is  an  array  [1  TO  4]  of  character  which 

represents  a  four  digit  number.  To  obtain  the  numerical 
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value  of  the  character  string,  the  programmer  can  use  the 
following  code. 

I  :=  1  %  I  and  M  are  integer  variables 

M  :=  0 

LOOP  WHILE  I<=4 

M  :=  M*10+CVCI[  A[  I  ]]-CVCI[  *0*  ] 

I  :=  1+1 
REPEAT 

I  is  a  counter.  When  the  loop  statement  has  been  executed,  M 
will  contain  the  numerical  value  of  the  character  string 
contained  in  A. 

Note  that  OLGA  does  not  check  the  integer  value  to  see 
whether  the  integer  is  a  legal  ASCII  code  representation  of  a 
Character  in  the  CVIC  function.  It  is  the  programmer  who 
must  do  the  check. 

CVIB ,  Convert  Integer  to  Bits  Function 

This  function  has  the  following  implicit  declaration: 
CVIB  :  FUNCTION  [INTEGER]  RETURNS  BITS 

The  convert  integer  to  bits  function  requires  a  single 

argument  of  type  integer.  It  returns  to  the  calling  program 
the  corresponding  bits  value  of  the  integer. 

Example:  CVIB  [10]  returns  the  bits  value  "12". 

CV El ,  Convert  Bits  to  Integer  Function. 

This  function  has  the  following  implicit  declaration: 
CVBI  :  FUNCTION  [BITS]  RETURNS  INTEGER 

The  convert  bits  to  integer  function  requires  a  single 

argument  of  type  bits.  It  returns  to  the  calling  program  the 
corresponding  integer  value  of  the  bits  argument. 

Example:  CVBI  ["15"]  returns  the  integer  13. 

CVBI  [L>K]  returns  an  integer  value  of  1  if  L  is  greater  than 
K  and  0  if  L  is  less  than  or  equal  to  K. 

9.3  Input,  Output  Functions  and  Procedures. 

The  Input/Output  functions  and  procedures  are  used  to  control 
the  transmission  of  information  between  the  computer  and  I/O 
devices.  The  number  and  type  of  I/O  devices  available 
depends  on  the  version  of  OLGA  that  is  being  used  (See 
APPENDIX  A).  The  devices  are  identified  by  a  "unit  number". 
All  versions  of  OLGA  have  a  teletype  as  input  and  output  unit 
0.  The  other  unit  numbers  depend  on  the  version,  but  an 
example  configuration  is: 


INPUT  DEVICES: 
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The  teletype  keyboard/paper  tape  reader  (UNIT=0) . 

The  card  reader  (UNIT=1) . 

The  high  speed  paper  tape  reader  (UNIT=2) . 

OUTPUT  DEVICES: 

The  teletype  printer/paper  tape  punch  (UNIT=0) • 

The  line  printer  (UNIT=1). 

The  high  speed  paper  tape  punch  (UNIT=2) . 

II,  Input  Integer  Function : 

The  input  integer  function  has  the  following  implicit 
declarat ion : 

II  :  FUNCTION  [INTEGER]  RETURNS  INTEGER 

The  input  integer  function  will  read  the  next  integer  from 
the  input  device  whose  unit  number  is  passed  as  an  argument. 

When  the  II  functiom  is  called,  it  will  read  and  skip  over 
all  non  numeric  characters.  Once  the  II  function  meets  a 
numeric  character,  it  will  continue  reading  until  it  meets  a 
non  numeric  character  such  as  a  comma,  a  blank  or  a  CR.  At 
this  point,  the  II  function  will  return  the  value  of  the 
integer  that  was  read. 

Example:  The  following  statement  causes  an  integer  to  be 

read  from  the  teletype  and  to  be  assigned  to  J. 

J  :=  II  [0]  %  Read  integer  from  teletype. 

IC ,  Input  Character  Function: 

The  input  character  function  has  the  following  implicit 
declaration: 

IC  :  FUNCTION  [INTEGER]  RETURNS  CHARACTER 

The  input  character  function  will  read  the  next  character  the 
input  device  whose  unit  number  is  passed  as  an  argument. 

Example:  The  following  statement  causes  a  character  to  be 

read  from  the  teletype  and  to  be  assigned  to  C. 

C  :=  IC  [0]  %  Read  character  from  teletype 

I A ,  Input  Array  Procedure 

The  input  array  procedure  has  the  following  implicit 
declaration: 

IA  :  PROCEDURE  [ARRAY  [ INTEGER ]OF  CHARACTER,  INTEGER,  INTEGER] 
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The  input  array  procedure  will  read  a  string  of  characters 
the  input  device  whose  unit  number  is  passed  as  the  third 
argument. 

First  argument  =  Name  of  array  of  characters  whose  lower  bound 

is  zero. 

Second  argument  =  Name  of  an  integer  variable.  When  IA  has  been 

executed,  the  variable  will  contain  the  number 
of  characters  which  were  read. 

Third  argument  =  Unit  number  of  input  device. 

When  the  IA  procedure  is  called,  it  will  read  into  the  array 
the  character  string  until  it  meets  the  CR/LF  character.  The 
CR  (carriage  return)  character  is  put  in  the  array,  but  not 
the  LF  (linefeed)  character.  The  IA  procedure  will  assign  to 
the  second  parameter  the  number  of  characters  that  were  read, 
including  the  CR. 

EXAMPLE :  The  following  procedure  invocation  statement  causes 

the  next  character  string  to  be  read  into  the  Array  of 
characters  A.  NUM  will  contain  the  number  of  characters  that 
were  read. 

IA  [A,  NUM,  0]  %  Read  character  string  from  teletype  unit. 

01 ,  Output  integer  procedure : 

The  output  integer  procedure  has  the  following  implicit 
declaration: 

01  :  PROCEDURE  [ INTEGER,  INTEGER] 

The  output  integer  procedure  will  print  (or  punch)  an  integer 
on  the  device  specified  by  the  second  argument.  No  CR/LF  is 
printed  after  the  integer. 

First  argument  =  An  integer  expression.  The  Value  of  the 

expression  is  printed  (or  punched) 

Second  argument  =  output  device  unit  number. 

Example:  The  following  procedure  invocation  statement  will 

cause  the  integer  value  of  J  to  be  printed  on  the  teletype. 

01  [J,  0]  %  J  is  an  integer  variable. 

0C,  Output  character  procedure: 

The  output  character  procedure  has  the  following  implicit 
declaration: 

OC  :  PROCEDURE  [CHARACTER,  INTEGER] 

The  output  character  procedure  will  print  (or  punch)  a 
character  on  the  device  specified  by  the  second  argument. 


First  argument  =  A  character  expression.  The  value  of  this 

expression  is  printed  (punched) 

Second  argument  =  output  device  unit  number. 

Example:  The  following  procedure  invocation  statement  will 

cause  the  character  value  of  C  to  be  printed  on  the  teletype. 

OC  [C,  0]  %  C  is  a  character  variable. 

Note:  If  a  CR  is  passed  to  OC,  then  CR  and  LF  characters  are 

printed  (or  punched) .  CR  has  an  ASCII  representation  egual 
to  13.  Therefore  the  CR  character  in  OLGA  is  CVIC  [13]. 

0 A ,  Output  Array  procedure 

The  output  array  procedure  has  the  following  implicit 
declaration: 

OA  :  PROCEDURE  [ARRAY  [INTEGER*]  OF  CHARACTER ,  INTEGER,  INTEGER] 

The  output  array  procedure  will  print  (or  punch)  a  number  of 
elements  of  an  array  of  characters  using  the  device  specified 
by  the  third  argument. 

First  argument  =  Reference  to  an  array  of  characters  whose 

lower  bound  must  be  zero. 

Second  argument  =  Number  of  elements  of  array  of  characters 

which  will  be  printed  (or  punched) 

Third  argument  =  output  device  unit  number 

*  A  number  greater  than  zero  must  be  specified. 

Example:  The  following  procedure  invocation  statement  causes 

the  first  10  elements  of  the  array  of  characters.  A,  to  be 
printed  on  the  teletype. 

OA  [A,  10,  0]  %  Print  the  first  10  characters  of  array 

%  of  characters  A. 

9.4  REFER  function 

REFER  is  a  function  which  has  a  single  argument.  This 

argument  must  be  a  variable.  The  value  which  the  REFER  function 

returns  to  the  calling  program  is  a  pointer  to  this  variable. 
Note  that  if  this  pointer  value  is  assigned  to  a  pointer 

variable,  then  the  pointer  variable  must  be  of  type  Pointer  to 

the  type  of  the  variable.  The  variable  used  as  argument  for  the 
REFER  function  must  NOT  be  a  parameter  of  a  subprogram. 

Example: 

P  :=  REFER  [I]  % 

% 

% 

% 

% 


This  statement  is  valid  only  if  P  is 
of  type  Pointer  to  the  type  of  variable 
I.  For  example,  if  I  is  an  integer 
variable  then  P  must  be  of  type 
Pointer  to  Integer. 
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9.5  Dynamic  allocation  and  deallocation  functions 
ALLOC ,  Allocate  space  for  a  type 

ALLOC  is  a  single  argument  pseudo  function  that  is  used  to 
create  variables  during  execution.  ALLOC  has  as  its  single 
argument  a  record_type.  This  type  is  used  to  declare  the 
properties  of  the  dynamically  created  variable.  The  invocation 
of  ALLOC  causes  memory  to  be  allocated  to  a  dynamically  created 
variable  of  this  type  and  a  pointer  pointing  to  the  variable  to 
be  returned  to  the  calling  program.  Note  that  the  appearance  of 
a  record  type  as  argument  of  ALLOC  causes  the  declaration  of  that 
record  type.  The  declaration  of  record  type  in  ALLOC  follows 
exactly  the  same  rules  as  the  declaration  of  record  type  in 
record  declarations  (See  6.3.3).  Hence,  the  declarations  of 
record  types  in  ALLOC  must  be  consistent  with  the  declarations 
made  in  the  declaration_blocks  of  the  subprograms. 

Example : 

P :  =  ALLOC  [RECORD  [  NAME : ARB  AY  [6]  OF  CHARACTER,  # 

SON : POINTER  TO  RECORD]] 

After  this  statement  is  executed  P  will  point  to  a  record. 
NAME  and  SON  will  now  be  defined  as  above.  If  NAME  or  SON  have 
been  declared  differently  in  the  declaration  block  of  the 
subprogram,  an  error  will  occur.  If  there  is  no  storage 
available,  the  program  will  attempt  to  do  a  garbage  collection. 
If  there  still  is  not  enough  storage,  the  program  will  halt. 

51 ALLOC,  Deallocate  space  for  a  type 

DEALLOC  is  a  single  argument  procedure  which  is  used  to 
deallocate  storage  during  execution.  It  is  passed  as  argument  a 
pointer  to  a  variable  which  was  previously  created  by  ALLOC.  It 
frees  the  space  associated  with  the  pointed  at  variable.  Any 
attempt  to  access  that  variable  through  any  pointer  after  return 
from  DEALLOC,  will  be  treated  as  if  the  pointer  was  NULL. 

9.6  Shift  Functions 

The  Shift  functions  are  used  to  shift  all  the  bits  in  a  bits 
value  by  one  place.  The  Shift  functions  are  useful  to  the 
programmer  who  wants  to  pack  information  in  a  bits  variable. 

ASL,  Arithmetic  Shift  Left: 

The  Arithmetic  Shift  Left  function  has  the  following  implicit 
declaration. 

ASL  :  FUNCTION  [BITS]  RETURNS  BITS 

The  Arithmetic  Shift  Left  function  reguires  one  argument  of 
type  bits.  It  shifts  all  the  bits  in  the  argument  by  one  place 
to  the  left.  Bit  0  is  loaded  with  0;  Bit  15  is  lost.  The  ASL 
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function  returns  to  the  calling  program  this  shifted  bits  value. 
The  argument  remains  unchanged. 


ASR,  Arithmetic  Shift  Right: 

The  Arithmetic  Shift  Right  function  has  the  following  implicit 
declaration. 

ASR  :  FUNCTION  [BITS]  RETURNS  BITS 

The  Arithmetic  Shift  Right  function  requires  one  argument  of 
type  bits.  It  shifts  all  the  bits  in  the  argument  by  one  place 
to  the  right.  Bit  15  is  replicated.  Bit  0  is  lost.  The  ASR 
function  returns  to  the  calling  program  this  shifted  bits  value. 
The  argument  remains  unchanged. 
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CHAPTER  10 

Program  Organization 

A  source  program  is  made  up  of  the  list  of  definitions  of  the 
abstractions  and  modules  in  the  program#  This  chapter  describes 
the  arrangement  of  the  definitions  of  the  abstractions  and  the 
modules  in  a  source  program.  The  rules  on  the  use  of  identical 
names  to  represent  different  quantities  in  different  parts  of  a 
program  are  also  given  in  this  chapter. 

1C.1  Arrangement  of  Abstractions  and  Modules. 

The  only  restrictions  on  the  relative  positions  of 
abstractions  and  modules  in  a  source  program  is  given  by  the 
following  rules. 

Rules 

1.  The  definition  of  any  of  the  data_blocks  of  the  program  must 
always  precede  the  definitions  of  all  the  subprograms  which  use 
its  variables. 

2.  The  definition  of  any  literal  must  always  precede  all  the 
occurrences  of  its  name  except  for  the  occurrences  in  export 
clauses  of  modules. 

3.  The  definition  of  any  user  defined  type  must  always  precede 
all  the  occurrences  of  its  name  except  for  the  occurrences  in 
export  clauses  of  modules. 

At  the  end  of  the  list  of  definitions  of  subprograms  and 
data_blocks  which  make  up  the  source  program,  there  must  be  a 
source  program  record  whose  first  character  is  the  $  character. 
This  source  program  record  signals  to  the  compiler  the  physical 
end  of  the  source  program. 
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Example:  The  following  is  a  valid  program. 
DATA  G10BAI 


END  GICBAI 


PROCEDURE  MAIN 


END 


MAIN 


%Main  declares  and  uses  non_local 
%variables  from  GLOBAL 


.  %  Definitions  of  other  subprograms 

.  %  and  other  data^blocks. 

$ 

The  following  is  an  invalid  program. 


PROCEDURE  MAIN 

• 

.  %  MAIN  declares  and  uses  non  local 

.  %  variables  from  data_block  GLOBAL 

• 

END  MAIN 
DATA  GLOBAL 


END  GLOBAL 

• 

.  %  Definition  of  other  subprograms 

.  %  and  data_blocks 

$ 

This  program  is  invalid  because  the  definition  of  the 
data_block  GLOBAL  does  not  precede  the  definition  of  a  subprogram 
(MAIN)  which  uses  its  variables. 

10.2  Rules  on  the  Use  of  Identical  Names  in  a  Program. 

The  rules  on  the  use  of  identical  names  in  a  program  to 
represent  different  data  items  are  given  below. 

1.  The  names  of  variables,  fields  of  records,  and  parameters 
which  are  declared  locally  by  a  subprogram  are  known  only  in  the 
executable_statement  list  of  this  subprogram.  In  other 
subprograms,  these  names  may  be  defined  to  represent  different 
data  items. 
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Example: 

PROCEDURE  A  [ B : I NTEGER  ] 
DECLARE 


END 


I : INTEGER 


DECLARE 


END  A 

PROCEDURE  C  [ E: CHAR ACTER  ] 
DECLARE 


I : BITS 


END 


END  C 


DECLARE 


In  the  executable_statement  list  of  A,  B  and  I  are  integer 
variables.  In  the  executable_statement  list  of  C,  B  is  a 
character  variable  and  I  is  a  bits  variable. 

2.  The  name  of  a  procedure,  function,  operator  or  data__block  may 
be  defined  in  a  subprogram  to  represent  a  different  data  item. 
In  this  case,  the  name  represents  the  data  item  in  the 
excutatle_statement_List  of  the  subprogram.  Outside  the 
executable_sta tement_List  of  the  subprogram,  the  name  stands  for 
the  procedure,  function,  operator  or  data_block.  Note  that  the 
subprogram  cannot  call  the  procedure,  function,  or  operator  or 
use  the  data  block  with  that  name. 
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Example: 

PROCEDURE  A 
DECLARE 


END  DECLARE 
END  A 

PROCEDURE  B 
DECLARE 


A : CHAR  ACTER 


END 


END  B 


DECLARE 


In  procedure  B,  A  is  a  character  variable.  B  cannot  call 
procedure  A.  Outside  the  executable_statement  list  of  procedure 
B,  A  is  a  procedure. 


3.  Two  abstractions  which  are  both  visible  at  any  one  point  in 
the  program  may  not  have  the  same  name.  However,  two 
abstractions  which  are  never  both  visible  at  any  one  point  in  the 
program  can  have  the  same  name. 

Example : 

MODULE  Ml  EXPORTS  B 

%  A  and  B  are  abstractions 
%  defined  here 

END  Ml 

MODULE  M2  EXPORTS  B 

%  A  and  B  are  abstractions 
%  defined  here. 

END  M2 

The  name  A  can  be  used  for  two  different  abstractions  because 
A  of  Ml  and  A  of  M2  are  net  both  visible  at  any  one  point  in  the 
program.  The  name  B  cannot  be  used  for  the  two  abstractions  of 
Ml  and  M2  because  outside  Ml  and  M2,  B  of  Ml  and  E  of  M2  are  both 
visible. 
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CHAPTER  1J. 

Executable  and  Non  Executable  Statements 
The  following  statements  are  executable  statements. 


1. 

2. 

3. 

4. 

5. 

6. 

7. 

8. 
9. 

10. 


The  replacement_statement 
The  exit_statement 
The  return_sta tement 
The  null_statement  (empty) 

The  case_statement 

The  if_then_else_statement 

The  when_then_statement 

The  loop_statement 

the  group_statement 

The  procedure_invocation_sta tement 


The  following  statements  are  non_executable. 

1.  Declare_statement 

2.  End_Declare_statement 

3.  Declaration_statement 

4.  Function_heading 

5.  Operator_heading 

6.  Procedure_heading 

7.  Data_block_heading 

8.  End_statement 

9.  Module_heading 

10.  Type_def inition 

11.  Literal  definition 
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Appendix  A 


Compiling  and  Running  OLGA  Programs 

In  order  to  run  a  job  using  the  OLGA  programming  system,  it 
is  necessary  to: 

1.  Prepare  the  source  program. 

2.  Compile  the  source  program. 

3.  Execute  the  object  code  produced  in  step  2. 

The  procedure  that  is  followed  to  run  the  OLGA  compiler  and 
to  execute  the  user's  object  program  depends  on  the  hardware  and 
the  software  that  is  available  at  the  site.  This  appendix 
describes  the  procedures  that  are  followed  for  two  versions  of 
the  OLGA  compiler.  These  versions  are: 


1.  The  version  of  the  compiler  stored  on  paper  tape.  This 
will  be  referred  as  the  Paper  Tape  Version  of  the  Compiler. 
It  operates  in  a  Load  and  Go  Mode. 

2.  The  version  of  the  compiler  stored  on  disk  and  operating 
under  the  RT 1 1  operating  system.  This  version  will  be 
referred  as  the  RT11  Disk  Version  of  the  Compiler.  It  also 
operates  in  a  Load  and  Go  mode. 

A- 1  The  Paper  Tape  Version  of  the  Compiler 


This  version  of  the  compiler  is  stored  on  paper  tape  and, 
once  it  has  been  loaded  into  memory,  it  can  compile  a  user's 
program.  It  reads  the  source  program  from  an  input  device  (a 
card  reader) ,  it  compiles  and  stores  the  resultant  object  program 
in  memory,  and  it  produces  a  listing  of  the  program  together  with 
any  error  messages  on  an  output  device  (a  line  printer) .  Once  a 
program  has  been  successfully  compiled,  it  can  be  executed. 
During  execution,  a  program  can  read  data  from  the  card  reader 
(unit  number=1) ,  the  high  speed  paper  tape  reader  (unit 
number=2) ,  or  the  teletype  (unit  number=0).  It  can  also  print 
data  using  the  line  printer  (unit  number=1) ,  the  high  speed  paper 
tape  punch  (unit  number=2) ,  or  the  teletype  (unit  number=0) . 


The  compiler  does  not  have  to  be  loaded  again  following  the 
compilation  and  execution  of  a  program  in  order  to  compile 
another  program.  It  can  compile  successively  one  or  more 
programs,  provided  that  the  execution  of  one  of  these  programs 
has  net  destroyed  the  copy  of  the  compiler  in  core.  If  it  has 
been  destroyed,  a  fresh  copy  of  the  compiler  should  be  loaded 
into  memory  in  order  to  compile  another  program. 

A-1. 1  loading  the  Paper  tape  Version  of  the  Compiler  into  Core 

The  compiler  may  be  loaded  into  core  in  one  of  two  ways: 


1 .  Use  a  hardware  Loader 
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or  2.  Use  the  Bootstrap  Loader  and  the  Absolute  Loader. 

A-1.1.1  The  Hardware  Loader 

Refer  to  the  instructions  at  the  site. 

A- 1.  1.2  The  Boostrap  Loader  and  the  Absolute  Loader 

A  system  program  is  used  to  load  in  core  the  compiler.  This 
system  program  itself  must  be  somehow  loaded  into  core.  The 
steps  taken  to  load  data  into  core  are  shown  below. 

Load  Bootstrap  Loader 
Method  to  Load:  Toggle  using  Front 
Panel  switches 

I 

I 

V 

Load  Absolute  Loader 
Method  to  Load:  Use  Bootstrap  Loader 

I 

I 

V 

Load  Compiler 

Method  to  Load :  Use  Absolute  Loader 


The  Bootstrap  Loader  is  a  program  which  instructs  the 
computer  to  accept  and  store  in  core  data  which  is  punched  on 
paper  tape  in  bootstrap  format.  The  Bootstrap  Loader  is  used  to 
load  very  short  paper  tape  programs  —  primarily  the  Absolute 
Loader . 


The  Absolute  Loader  is  a  system  program  which  enables  you  to 
load  into  any  available  core  memory  bank  data  punched  on  paper 
tape  in  absolute  binary  format. 

A-1. 1.2.1  The  Bootstrap  Loader 


The  Bootstrap  Loader  should  be  loaded  (toggled)  into  the 
highest  cere  memory  bank.  The  locations  and  corresponding 
instructions  of  the  Bootstrap  Loader  are  listed  and  explained 
below. 


Location 

XX  774  4 
XX7746 
XX7750 
XX7752 
XX7754 
XX7756 


Instruction 

016701 

000026 

012702 

000352 

005211 

105711 
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XX7760 

XX7762 

XX7764 

XX7766 

XX7770 

XX7772 

XX7774 

XX7776 


100376 

116162 

000002 

XX7400 

005267 

177756 

000765 


YYYYY  —  TO  OSE: 

1)  Teletype  paper  tape 
Reader:  177560 

2)  High  speed  paper  tape 
Reader:  177550 


In  the  table  above,  XX  depends  on  the  memory  size  available 
on  the  computer.  For  example,  the  first  location  of  the  Loader 
would  be  one  of  the  following,  and  XX  in  all  subsequent  Locations 
would  be  the  same  as  the  first. 


Location 


Memory  Size 


017744 
037744 
057744 
077744 
1  17744 
1 37744 
157744 


4K 
8K 
12K 
16K 
20K 
24  K 
28K 


Loading  the  Bootstrap  Loader  into  Core: 

Toggle  in  the  Bootstrap  Loader  as  explained  below. 

1.  Set  XX7744  in  the  SWITCH  REGISTER  (SR)  and  press  LOAD 
Address  (XX7744  will  be  displayed  in  the  Address  Register). 

2.  Set  the  first  instruction,  016701,  in  the  SR  and  list 
DEPosit  (016701  will  be  displayed  in  the  Data  Register). 

Note:  When  DEPositing  data  into  consecutive  words,  the  DEPosit 

automatically  increments  the  ADDress  Register  to  the  next  word. 

3.  Set  the  next  instruction,  000026,  in  the  SR  and  LIFT 
DEPosit  (000026  will  be  displayed  in  the  DATA  register). 

4.  Set  the  next  instruction  in  the  SR,  press  DEPosit  and 
continue  depositing  subsequent  instructions  (ensure  that 
location  XX7766  reflects  the  proper  memory  size)  until  after 
000765  has  been  deposited  in  location  XX7774. 

5.  Deposit  the  desired  device  status  register  address  in 
location  XX7776,  the  last  location  of  the  Bootstrap  Loader. 

It  is  good  programming  practise  to  verify  that  all 
instructions  are  stored  correctly.  This  is  done  by  proceeding  at 
step  6  below. 

6.  Set  XX7744  in  the  SR  and  press  Load  Address. 

7.  Press  EXAMine  (the  octal  instruction  in  location  XX7744 
will  be  displayed  in  the  DATA  register  so  that  it  can  be 
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compared  to  the  correct  instruction,  016701.  If  the 

instruction  is  correct  proceed  to  step  8,  otherwise  go  to 
step  10. 

8.  Press  EXAMine  (the  instruction  of  the  location  displayed 

in  the  Address  Register  will  be  displayed  in  the  DATA 
register;  compare  the  Data  Register  contents  to  the 

instruction  for  the  displayed  location. 

9.  Repeat  step  8  until  all  instructions  have  been  verified  or 

go  to  step  10  whenever  the  correct  instruction  is  not 

displayed. 

Whenever  an  incorrect  instruction  is  displayed,  it  can  be 
corrected  by  performing  steps  10  and  11. 

10.  With  the  desired  location  displayed  in  the  Address 
Register,  set  the  correct  instruction  in  the  SR  and  lift 
DEPosit  (the  contents  of  the  SR  will  be  deposited  in  the 
displayed  location) . 

11.  PressExamine  to  ensure  that  the  instruction  was  correctly 
stored.  (It  will  be  displayed  in  the  Data  Register). 

12.  Proceed  at  step  9  until  all  instructions  have  been 

verified. 

The  Bootstrap  Loader  is  now  loaded  into  core. 

A-1.  1.2.2  Loading  the  Absolute  Loader 

1.  With  Bootstrap  Loader  in  core.  Set  Enable/Halt  to  Halt. 

2.  Place  the  Absolute  Loader  Tape  in  specified  reader.  Code 
351  must  be  over  reader  sensors. 

3.  Set  SR  to  XX7744. 

4.  Press  Load  Addr. 

5.  Set  Enable/Halt  to  Enable. 

6.  Press  start. 

7.  Tape  reads  in  and  stops  at  end  of  Data.  Absolute  Loader 
is  now  in  Core. 

A-1. 1.2.3  Loading  the  Compiler 

1.  With  the  Absolute  Loader  in  core,  set  Enable/Halt  to  Halt. 

2.  Place  the  Compiler  or  the  Editor  tape  in  specified  reader. 

3.  Set  the  SR  to  XX7500. 

4.  Press  Load  Addr. 

5.  Set  Enable/Halt  to  Enable. 

6.  Press  start. 

7.  Tape  readin.  The  compiler  is  now  in  core. 

A-1. 2  Compiling  a  Program  Using  The  Paper  Tape  Version  of  the 
Compiler 

If  the  Compiler  is  in  core  but  the  PDP-11  is  not  running, 
then  you  should  do  the  following  steps: 

1.  Set  the  Enable/Halt  to  Halt 

2.  Set  the  SR  to  Start  Address  =  1400  for  Compiler 
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3.  Press  Load  Addr 

4.  Set  the  Enable/Halt  to  Enable 

5.  After  insuring  that  the  source  program  is  ready  at  the 
input  device,  press  start.  The  Compiler  Program  is  now  in 
execution  and  should  print  a  message  on  the  teletype. 

6.  The  program  is  compiled  and  a  listing  of  programs  together 
with  any  error  messages  is  produced  on  the  listing  device. 
When  the  compilation  is  finished,  the  machine  should  halt. 

7.  If  you  wish  to  run  the  compiled  program,  press  continue. 
Execution  of  the  program  should,  normally,  begin  and  when  it 
has  finished,  the  machine  should  halt  again. 

8.  If  you  wish  to  rerun  the  compiled  program,  press  continue 
if  execution  of  the  program  was  terminated  in  the  manner 
described  in  step  7.  If  execution  of  the  program  in  Step  7 
was  terminated  by  setting  the  Halt/Enable  switch  to  Halt, 
then  the  program  can  be  restarted  by  following  Steps  1-5  with 
the  SR  address  in  Step  2  changed  to  the  "XFER  ADDR"  which 
should  be  posted  at  the  site. 

9.  To  compile  another  program,  start  at  Step  1.  If  any  of 
the  steps  1-6  fails,  it  may  be  that  the  copy  of  the  compiler 
in  core  was  destroyed.  In  this  case,  a  fresh  copy  of  the 
compiler  should  be  loaded  into  core. 

A-2  The  RT 1 1  Disk  Version  of  the  Compiler 

This  version  of  the  compiler  is  stored  on  disk  and  it 
operates  under  the  RT11  operating  system. 

Once  the  compiler  is  loaded  into  memory  and  is  running,  it 
reads  the  source  program,  it  compiles  and  stores  the  resultant 
object  program  in  memory  and  it  produces  a  listing  of  the  program 
together  with  any  error  messages.  All  input  and  output  is  done 
through  this  operating  system. 

In  order  to  specify  the  input  and  output  devices  which  are  to 
be  used  in  the  compilation  and  execution  of  programs,  RT11 
commands  must  be  entered.  The  following  is  a  brief  description 
of  these  commands.  (For  more  information,  see  the  RT11  System 
Reference  Manual,  DEC-1 1-ORUG A-C- E) . 

A-2. 1  RT 1 1  Input  and  Output  Commands. 

An  RT11  device  name  is  a  two  or  three  character  code  followed 
by  a  colon.  Some  common  device  names  are: 


CR  : 

Card  Reader 

LP  : 

Line  Printer 

DK  : 

Default  Device  (e.g.  , 

system  disk) 

DKn : 

Another  Device  of  the 
DK:  (n  is  an  integer)  . 

same  type  as 

TT  : 

Teletype  keyboard  and 

printer. 
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A  file  name  is  a  name  of  one  to  six  alphanumeric  characters, 
followed,  optionally,  by  a  period  and  an  extension  of  up  to  three 
alphanumeric  characters.  The  extension  to  a  file  name  generally 
indicates  the  format  of  the  file. 

A  file  specification  is  a  device  name  followed  by  a  filename 
(the  filename  is  used  only  for  file  structured  devices  such  as 
disks,  and  the  device  name  DK :  is  assumed  if  omitted). 

To  most  system  procedures,  you  specify  files  as  follows 
(system  responses  are  underlined) : 

*  list  of  output  files  =  list  of  input  files 

For  OLGA,  the  teletype  is  always  input  and  output  unit  0.  In 
addition,  output  units  1  and  2  and  input  unit  1  can  be  defined  at 
runtime  as  follows: 

*  output  file  1,  output  file  2  =  input  file  1 

Any  or  all  of  these  fields  may  be  omitted.  If  they  are 
omitted  and  the  program  uses  them,  then  no  input  or  output 
occurs. 

A-2.2  Starting  the  RT11  Operating  System 

First,  it  may  be  necessary  to  bootstrap  the  RT11  operating 
system . 

1 .  Press  Halt 

2.  Mount  the  system  device  and  get  it  ready  (e.g.,  put  a  disk 
pack  in  its  slot,  push  the  LOAD/RUN  switch  to  Run,  and  wait 
for  the  ready  light) . 

3.  If  there  is  a  hardware  bootstrap  loader,  put  its  address 
in  the  switch  register,  press  LOAD  ADRS,  move  the  Enable/Halt 
switch  to  Enable,  and  press  start.  Otherwise,  ask  the 
operator  at  the  site  to  bootstrap  RT11. 

4.  The  RT 1 1  message  should  appear  at  the  console.  This  is 
followed  by  an  input  prompt 

A- 2.  3  Compiling  a  Program  Using  the  RT11  Disk  Version  of  the 
Compiler 

To  compile  a  program,  do  the  following: 

1.  Type:  ^  RUN  OLGA  (followed  by  a  CR) 

or  PUN  dev :  OLGA  (followed  by  a  CR) 

The  device  may  be  necessary  if  OLGA  is  on  a  device  other  than 
the  default  device,  e.g.,  DK1:  which  is  the  second  disk  unit. 
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2.  The  compiler  will  prompt  with  an  asterik, 
and  listing  files  are  specified. 


to  which  the  source 


*  listing  file  specif ication=source  file  specification 

For  example,  to  compile  a  program  stored  on  cards,  and  to 
produce  the  listing  on  the  line  printer,  type: 

*  LP:=  CR:  (followed  by  carriage  return) 

If  using  file  names,  the  default  extensions  are:  . OLG  for 
source  and  ,LST  for  listing. 

3.  When  compilation  is  finished,  the  machine  will  start  at  step  1 
of  the  following.  (To  return  to  RT-11,  type  CNTRL  C,ie:  holding 
down  the  CNTRL  key  and  pressing  the  C  key  when  ever  the  prompt 
fcr  input  occurs.  Another  way  to  return  to  RT-11  is  to  bootstrap 
the  operating  system  again  or  to  restart  the  compiler  at  location 
1  400)  . 

A-2.4  Running  a  Program  under  the  RT11  Operating  System. 

After  step  3  in  A-2.3  has  been  executed,  the  execution  of  the 
compiled  program  will  start  with  a  prompt  for  runtime 
input/output  specifications.  If  you  wish  to  proceed  with  the 
execution  of  the  compiled  program  do  the  following: 


1.  Type: 

*  list  of  output  files=list  of  input  f iles  (CR) 

For  example,  to  make  output  unit  1  a  line  printer  and  to  omit 
the  other  units  (0  is  always  assumed  for  the  teletype) ,  type: 

*  LP:=  (carriage  return). 

2.  The  program  will  execute  and  once  execution  of  the  program  is 
finished,  the  machine  will  halt.  To  execute  the  program  once 
again,  press  continue.  This  will  start  you  at  Step  1. 

A-2.5  Notes  on  Input/Output 

RT 1 1  input  and  output  is  done  in  blocks  of  256  words.  The 
exception  to  this  is  the  teletype  (when  specified  by  unit  number 
0  rather  than  another  unit  number  and  using  TT:  in  the  file 
specification) .  This  means  that  if  you  want  to  work 
interactively  with  the  program,  (i.e. ,  seeing  results  right  away 
and  having  input  accepted  right  away) ,  you  should  use  unit  0. 
The  other  input  and  output  units  will  wait  until  256  words  (512 
characters)  have  accumulated  or  the  end  of  the  program  is  reached 
(for  output)  or  the  end  of  a  file  is  reached  (for  input:this  is 
CNTRL  Z  for  teletype  input  and  a  multipunch  -,  6,  0,  1,  6,  7,  8, 

9,  for  card  input).  A  conseguence  of  this  is  that  if  the 
execution  of  the  program  is  halted  by  using  the  front  pannel 
switch,  all  of  the  output  may  not  have  been  produced. 
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For  card  input,  the  trailing  blanks  are  trimmed  and  the 
carriage  return  and  line  feed  characters  are  added  by  RT11. 
(OLGA  removes  the  line  feed) . 


Appendix  B 


ERROR  MESSAGES 

CP01 :  SUPERFLUOUS  CHARACTERS  EEFORE  TERMINATOR  IGNORED.  THIS  CAN 
OCCUR  IN  A  WIDE  VARIETY  OF  SITUATIONS.  IT  OCCURS  WHEN  A 
COMPLETE  STATEMENT  HAS  BEEN  COMPILED  BUT  MORE  TEXT  BEFORE 
THE  TERMINATOR  HAS  BEEN  DETECTED.  AN  INSTANCE  OF  THIS  IS  A 
RETURN_ STATEMENT  WHICH  CONTAINS  AN  EXPRESSION  AND  WHICH 
OCCURS  IN  A  PROCEDURE.  PROCEDURES  ARE  NOT  ALLOWED  TO 
RETURN  VALUES. 

CP02:  AN  EXECUT A BLE_ STATEMENT  FOLLOWS  A  PROCEDURE,  FUNCTION  OR 
OPERATOR  DEFINITION.  IT  IS  COMPILED  BUT  WILL  NOT  EXECUTE. 

CP03:  INVALID  CHARACTERS  AFTER  THE  KEYWORD  "IF”  OR  "WHEN"  ASSUMED 
TO  BE  "THEN". 

CP04:  MISSING  "ELSE"  AFTER  "IF  <EXPR>  THEN  <ST ATEMENT>" •  A  NULL 
STATEMENT  IS  GENERATED  FOR  THE  "ELSE"  CONDITION. 

CP05:  INVALID  CHARACTERS  IN  C ASE_ST ATEMENT  CHANGED  TO  "LIMIT". 

CP06 :  INVALID  UPPER  LIMIT  FOR  CASE_ST ATEMENT.  1  IS  USED. 

CP07 :  INVALID  CHARACTERS  IN  CASE^ST ATEMENT  CHANGED  TO  "ELSE". 

CP08 :  INVALID  ELSE  NUMBER  IN  CASE_ST ATEMENT.  THE  NUMBER 
FOLLOWING  "LIMIT"  IS  USED  AS  ELSE  NUMBER. 

CP09:  THERE  IS  NO  NUMBER  LABEL  IN  A  STATEMENT  AFTER  A  CASE 
HEADING.  0  IS  USED. 

CP  10 :  NUMBER  LABEL  OUT  OF  SEQUENCE.  THE  LABEL  IS  CHANGED  TO  1 
MORE  THAN  PREVIOUS  LABEL. 

CPU:  INVALID  STATEMENT  ASSUMED  TO  BE  ESAC  STATEMENT. 

CP12 :  INVALID  CONDITION  TYPE  ASSUMED  TO  BE  "UNTIL". 

CP13 :  MISSING  NAME  AFTER  "PROCEDURE",  "FUNCTION",  "OPERATOR", 
"DATA",  "TYPE",  "LITERAL"  OR  "END". 

CPI  4:  INVALID  CHARACTERS  WHERE  "PROCEDURE",  "FUNCTION", 
"OPERATOR",  "MODULE",  "TYPE"  OR  "LITERAL"  IS  EXPECTED. 
ASSUMED  TO  BE  "PROCEDURE". 

CPI  5:  NAME  IN  END_ ST ATEMENT  IS  NOT  THE  SAME  AS  THE  PROCEDURE, 
DAT A_BLOCK,  FUNCTION,  OPERATOR,  OR  MODULE  NAME.  THE  NAME 
OF  THE  PROCEDURE  D ATA_BLOCK,  FUNCTION,  OPERATOR,  OR  MODULE 
IS  USED. 

CP16:  MISSING  ":=".  STATEMENT  DELETED.  OBJECT  PROGRAM  NOT 
EXECUTABLE. 
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CP17 :  ILLEGAL  EXPRESSION  ON  LEFT  SIDE  OF  REPLACEMENT  OPERATOR. 

(E. G. ,  AN  ARRAY  NAME  WITH  NO  SUBSCRIPT ,  OR  A  CONSTANT,  OR  A 
VALUE) .  THE  ASSIGNMENT  IS  DONE,  BUT  IT  MAY  CAUSE  A  RUN 
ERROR. 

CP  18 :  TOO  MANY  VARIABLES  OR  STATEMENTS  IN  THIS  PROGRAM. 
COMPILATION  IS  TERMINATED. 

CP19 :  NO  PROCEDURE  WITH  NAME  MAIN  FOUND.  OBJECT  PROGRAM  NOT 
EXECUTABLE. 

CP20:  THE  EXPRES ION  FOLLOWING  THE  KEYWORD  "IF”  OR  •'WHEN”  IS  NOT 
OF  TYPE  BITS.  THE  VALUE  OF  THE  EXPRESSION  IS  CONVERTED  TO 
A  BITS  VALUE  AND  IS  USED. 

CP21:  EXPRESSION  TYPE  FOR  CA SE_ST ATEMENT  NOT  INTEGER.  THE  VALUE 
OF  THE  EXPRESSION  IS  CONVERTED  TO  AN  INTEGER  VALUE  AND  IS 
USED. 

CP22 :  EXPRESSION  TYPE  FOR  LOOP_STATEMENT  NOT  BITS.  THE  VALUE  OF 
THE  EXPRESSION  IS  CONVERTED  TO  A  BITS  VALUE  AND  IS  USED. 

CP23 :  DIFFERENT  TYPES  IN  REPLACEMENT_ ST ATEMENT.  THE  VALUE  OF  THE 
EXPRESSION  ON  THE  R.H.S.  IS  CONVERTED  TO  THE  TYPE  OF  THE 
VARIABLE  ON  THE  L.H.S. 

CP24 :  "REFER"  IS  USED  ON  THE  LEFT  SIDE  OF  A  REPIACEMENT 
OPERATION.  THE  ASSIGNMENT  IS  NOT  DONE. 

CP25 :  A  PROCEDURE,  FUNCTION  OR  OPERATOR  WHOSE  NAME  WAS  DECLARED 
IN  A  DECLARATION  STATEMENT  IS  MISSING.  OBJECT  PROGRAM  IS 
NOT  EXECUTABLE. 

CP26 :  NO  CHARACTER  STRING  AFTER  "LITER AL="  (PERHAPS  THE  QUOTES 
WERE  LEFT  OUT).  A  NULL  STRING  IS  USED. 

CP27 :  A  MODULE  MAY  NOT  BE  DEFINED  INSIDE  ANOTHER  MODULE.  THE 
STATEMENT  IS  IGNORED. 

CP28 :  INVALID  CHARACTERS  AFTER  "LITERAL"  OR  "TYPE"  WERE  CHANGED 
TO  "=". 

CP29 :  NOT  EXPECTING  THE  KEYWORD  FOUND  AT  THE  BEGINNING  OF  THE 
STATEMENT.  THIS  CAN  HAPPEN,  FOR  EXAMPLE,  IF  "REPEAT" 
APPEARS  OUTSIDE  A  LOOP_ST ATEMENT.  THE  KEYWORD  IS  DELETED. 

CP30:  NOT  EXPECTING  "END"  HERE.  THIS  CAN  HAPPEN  IF  IT  APPEARS  IN 
A  LOOP_ STATEMENT,  GROUP  STATEMENT,  CONDITIONAL  STATEMENT  OR 
CASE  STATEMENT.  THE  CURRENT  PROCEDURE  (OR  FUNCTION, 
OPERATOR)  IS  ENDED  IMMEDIATELY. 

DC01:  MISSING  DECLARE  ST ATEMENT : DECLARE_STATEMENT  GENERATED. 
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DC02 :  SUPERFLUOUS  CHARACTERS  DELETED.  THIS  OCCURS  WHEN  A 
COMPLETE  DECLARATION_ST ATEM ENT  HAS  BEEN  COMPILED  BUT  MORE 
TEXT  BEFORE  THE  STATEMENT  TERMINATOR  HAS  BEEN  DETECTED. 

DC03 :  INVALID  SYMBOL  ENCOUNTERED.  THIS  OCCURS  WHEN  A  CHARACTER 
SUCH  AS  "d"  OR  A  KEYWORD  SUCH  AS  "TYPE"  OCCURS  WHERE  AN 
IDENTIFIER  IS  EXPECTED.  THE  INVALID  SYMBOL  IS  DELETED. 

DC04 :  DUPLICATE  DEFINITION  IGNORED. 

DC05:  INVALID  DELIMITER  IS  IGNORED.  :  OR  ]  IS  INSERTED  INSTEAD, 
DEPENDING  ON  CONTEXT. 

DC06:  MISSING  DATA_BLOCK  NAME  AFTER  "FROM".  THE 

D EC LARATION_ STATEMENT  IS  DELETED. 

DC07:  DAT A_BLOCK  DOES  NOT  EXIST,  IS  NOT  VISIBLE  (BY  SUITABLE 
IMPORTS/EXPORTS),  OR  DOES  NOT  APPEAR  BEFORE  THE  SUBPROGRAM 
WHICH  USES  ITS  VARIABLES.  THE  DECLARATION  IS  IGNORED. 

DC08:  THE  NON_LOC AL  VARIABLE  IS  NOT  DECLARED  IN  THE  SPECIFIED 
DATA_BLOCK.  THE  DECLARATION  OF  THE  VARIABLE  IS  IGNORED. 

DC09 :  THE  NON_LOCAL  VARIABLE  IS  OF  DIFFERENT  TYPE  IN  THE 
D AT A_BLOCK  WHERE  IT  IS  DEFINED.  THE  MOST  RECENT  TYPE  IS 
USED. 

DC10 :  ONLY  ONE  PROCEDURE,  OPERATOR,  OR  FUNCTION  CAN  BE  DECLARED 
IN  A  PROCEDURE,  OPERATOR,  OR  FUNCTION  DECLARATION 
STATEMENT.  THE  FIRST  ONE  IS  DECLARED,  THE  OTHERS  ARE 
IGNORED. 

DC1 1 :  INVALID  CHARACTERS  AFTER  THE  KEYWORD  "ARRAY".  THEY  WERE 
CHANGED  TO  A  [  . 

DC12:  AN  ARRAY  BOUND  WAS  NOT  A  NUMBER.  THIS  CAN  OCCUR  IF  AN 
IDENTIFIER  WHICH  IS  NOT  A  VISIBLE  LITERAL  IS  USED.  0  WAS 
USED. 

DC  1 3:  IN  AN  ARRAY  DECLARATION,  THE  SECOND  BOUND  WAS  LESS  THAN  THE 
FIRST  BOUND.  IT  WAS  CHANGED  TO  THE  FIRST  BOUND  +  1. 

DC1 4 :  INVALID  CHARACTERS  IN  ARRAY  DECLARATION  CHANGED  TO  ]. 

DC15:  MISSING  "OF"  IN  ARRAY  DECLARATION:  "OF"  IS  GENERATED. 

DC16 :  INVALID  TYPE.  INTEGER  USED. 

DC17:  TYPE  TOO  COMPLICATED  (ONLY  ABOUT  5  LEVELS  OF  "POINTER 
TO..."  OR  "ARRAY  OF..."  ARE  ALLOWED).  BEYOND  THIS  LEVEL, 
TYPES  WILL  NOT  BE  DIFFERENTIATED. 

DC18:  ARRAYS  OF  ARRAYS  NOT  ALLOWED.  CHANGED  TO  ARRAY  OF  INTEGER. 
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DC19:  INVALID  CHARACTERS  AFTER  THE  WORD  "RECORD”.  THEY  WERE 
CHANGED  INTO  A  [  . 

DC20 :  A  SDBFIELD  NAME  IN  A  RECORD  DECLARATION  IS  DECLARED 
DIFFERENTLY  IN  A  PREVIOUS  DECLARATION  OF  THE  SAME  TYPE  OF 
RECORD.  THE  FIRST  DECLARATION  IS  USED. 

DC21 :  UNDECOEABLE  TYPE.  THE  STATEMENT  IS  DELETED. 

DC22 :  THE  ARGUMENT  TYPES  DIFFER  FROM  A  PREVIOUS  DECLARATION  OF 
THIS  PROCEDURE,  FUNCTION,  OR  OPERATOR.  THE  PREVIOUS 
DECLARATION  IS  USED. 

DC23 :  TOO  MANY  ARGUMENTS  OF  SUBPROGRAMS.  TRY  USING  MORE 
NON_LOCAL  VARIABLES.  COMPILER  HALTS. 

DC24:  MISSING  "RETURNS"  IN  FUNCTION  OR  OPERATOR  DEFINITION. 
"RETURNS"  IS  GENERATED. 

DC25:  A  NAME  FOR  ONE  OF  THE  PARAMETERS  OF  A  FUNCTION,  PROCEDURE, 
CR  OPERATOR  HAS  NOT  BEEN  GIVEN.  THE  PROCESSING  OF  THE 
PARAMETER  LIST  IS  TERMINATED. 

DC26 :  OVERFLOW  OF  THE  SPACE  USED  TO  HOLD  THE  TYPES  OF  ARGUMENTS 
OF  PROCEDURES,  FUNCTIONS,  AND  OPERATORS.  COMPILER  HALTS. 
TRY  USING  MORE  NON_LOC AL  VARIABLES. 

DC27 :  MORE  THAN  30  SYMBOLS  IN  ONE  DECLARATION.  THE  FIRST  30  ARE 
PROCESSED,  THE  REST  IGNORED. 

DC28 :  DIFFERING  TYPE  IN  PROCEDURE,  FUNCTION,  CR  OPERATOR 
DEFINITION.  THE  FIRST  ONE  IS  USED. 

DC29 :  INVALID  SUBFIELD  NAME  IN  RECORD.  THE  RECORD  DECLARATION  IS 
CHANGED  TO  INTEGER. 

DC30 :  MISSING  "TO"  AFTER  "POINTER".  "TO"  IS  GENERATED. 

DC31 :  STATIC  RECORDS  ARE  NOT  ALLOWED  IN  REENTRANT  PROCEDURES. 
USE  ALLOC  TO  GET  SPACE  AT  RUNTIME. 

DC32:  FUNCTIONS  AND  OPERATORS  CAN  NOT  RETURN  ARRAYS  OR  RECORDS. 
INTEGER  USED. 

GNO 1 :  SOURCE  PROGRAM  CONTAINS  DIVISION  BY  ZERO  AT  COMPILE  TIME. 
DIVISION  BY  1  IS  PERFORMED  INSTEAD. 

GN02:  TOO  MANY  VARIABLES  IN  THIS  PROGRAM.  COMPILER  HALTS. 

GN03:  COMPILER  ERROR.  POSSIBLE  CAUSE:  NESTING  TOO  DEEP.  TAKE 
YOUR  LISTING  TO  ADVISOR. 

GN04:  COMPILER  ERROR.  TAKE  YOUR  LISTING  TO  ADVISOR. 
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GN05 : 

RNOIs 

RN02: 

RN03 : 

RN04 : 

RN05: 
RN06 : 

SC0 1 : 

SC02 : 

SC03: 

SC04r 
SR0 1 : 

XPOI : 

XP02: 
XP03: 
XP04 : 
XP05: 
XP06: 


END  OF  FILE  REACHED  WHEN  NOT  EXPECTED.  CHECKED  FOR 
PRESENCE  OF  "$"  OR  UNMATCHED  QUOTE. 

DIVISION  BY  ZERO  AT  RUN  TIME.  PROGRAM  STOPS. 

NO  MORE  SPACE  CAN  BE  COLLECTED  TO  DO  THE  ALLOC.  PROGRAM 
STOPS. 

ADDRESSING  ERROR.  THIS  CAN  HAPPEN  IN  A  NUMBER  OF  CASES: 
YOU  ATTEMPTED  TO  RUN  A  PROGRAM  WITH  ERRORS  IN  IT  (SUCH  AS 
MISSING  PROCEDURE) ,  A  SUBSCRIPTED  REFERENCE  WAS  TO  A 
NONEXISTANT  MEMORY  LOCATION  (TRY  LEAVING  SUBSCRIPT  CHECKING 
TURNED  ON) ,  AN  I/O  DEVICE  IS  UNATTACHED,  OR  THERE  IS  A 
COMPILER  ERROR  (TAKE  YOUR  LISTING  TO  ADVISOR).  PROGRAM 
STOPS. 

COMPILER  ERROR  (IF  THERE  WERE  NO  ERRORS  DETECTED  IN  THE 
PROGRAM).  TAKE  YOUR  LISTING  TO  ADVISOR. 

END  OF  FILE  ON  INPUT.  PROGRAM  STOPS. 

SUBSCRIPT  OUT  OF  BOUNDS  AT  RUN  TIME.  THE  NUMBER  PRINTED 
IMMEDIATELY  BEFORE  ON  THE  ERROR  MESSAGE  DEVICE  IS  THE  LINE 
NUMBER  BEING  EXECUTED.  PROGRAM  STOPS. 

SYMBOL  IS  TOO  LONG.  ONLY  9  CHARACTERS  ARE  ALLOWED.  THIS 
MUCH  IS  USED. 

LITERAL  AND/OR  TYPE  NESTING  >  4  DEEP.  NO  MORE  EXPANSION  IS 
DONE  BELOW  THIS  LEVEL. 

THERE  IS  AN  INVALID  CHARACTER  IN  A  BITS  CONSTANT.  "  IS 
INSERTED  BEFORE  IT. 

INVALID  CHARACTER.  IT  IS  IGNORED. 

INPUT  RECORD  IS  TOO  LONG.  A  RECORD  (E.G.,  CARD)  UP  UNTIL 
A  OR  END  OF  RECORD,  WITH  BLANKS  REMOVED  SUCH  THAT 

THERE  IS  NEVER  MORE  THAN  1  BLANK  IN  A  ROW,  MUST  NOT  EXCEED 
80  CHARACTERS.  THIS  MUCH  IS  USED. 

A  VAFIA-BLE  REFERENCE,  A  PROCEDURE  CALL,  OR  A  FUNCTION  CALL 
CANNOT  CCCUR  HERE.  IT  IS  DELETED. 

♦  CANNOT  OCCUR  HERE.  IT  IS  DELETED. 

-  CANNOT  CCCUR  HERE.  IT  IS  DELETED. 

THE  NOT  OPERATOR  CANNOT  OCCUR  HERE.  IT  IS  DELETED. 

MONADIC  OPERATOR  CALL  CANNOT  OCCUR  HERE.  IT  IS  DELETED. 

DYADIC  OPERATOR  CALL  CANNOT  OCCUR  HERE.  IT  IS  DELETED. 


XP07 


(  CANNOT  OCCUR  HERE.  IT  IS  DELETED. 
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XP08 : 

) 

CANNOT 

CCCUR 

HERE. 

IT 

IS 

DELETED. 

XP09  : 

C 

CANNOT 

OCCUR 

HERE. 

IT 

IS 

DELETED. 

XP10: 

[ 

CANNOT 

OCCUR 

HERE. 

IT 

IS 

DELETED. 

XP11 : 

] 

CANNOT 

OCCUR 

HERE. 

IT 

IS 

DELETED. 

XP  12 : 

9 

CANNOT 

OCCUR 

HERE. 

IT 

IS 

DELETED. 

XP13 : 

• 

CANNOT 

OCCUR 

HERE. 

IT 

IS 

DELETED. 

XP14: 

d 

CANNOT 

OCCUR 

HERE. 

IT 

IS 

DELETED. 

XP  15: 

6 

CANNOT 

CCCUR 

HERE. 

IT 

IS 

DELETED. 

XP1 6  : 

1 

CANNOT 

OCUR  ! 

HERE. 

IT  IS 

DELETED. 

XP 17 :  RELATIONAL  OPERATOR  CANNOT  CCCUR  HERE.  IT  IS  DELETED. 

XP 18 :  TERMINATOR  OR  KEYWORD  CANNOT  OCCUR  HERE.  THE  EXPRESSION  IS 
NOT  COMPILED  ANY  FURTHER. 

XP19 :  UNDECLARED  IDENTIFIER  ENCOUNTERED.  THE  NUMBER  1  IS  USED. 

XP20:  MISSING  INDEX  IN  ARRAY.  0  IS  USED. 

XP21  :  INCORRECT  TYPE  OPERAND.  THE  VALUE  OF  THE  OPERAND  IS 
CONVERTED  TO  THE  TYPE  OF  VALUE  THAT  IS  EXPECTED  BY  THE 
OPERATOR  AND  IS  USED. 

XP22 :  EXPECTING  PROCEDURE  OR  FUNCTION  NAME,  BUT  NONE  FOUND.  THE 
ARGUMENTS  ARE  DELETED  AND  THE  NUMBER  1  IS  SUBSTITUTED. 

XP23 :  SUBSCRIPT  NOT  AN  INTEGER.  THE  SUBSCRIPT  VALUE  IS  CONVERTED 
TO  AN  INTEGER  AND  IS  USED. 

XP24 :  ATTEMPT  TO  SUBSCRIPT  CONSTANT  OR  A  VARIABLE  THAT  IS  NOT  AN 
ARRAY.  SUBSCRIPTION  IS  PERFORMED,  BUT  RESULT  IS 
MEANINGLESS. 

XP25 :  SUBSCRIPT  OUT  OF  BOUNDS  AT  COMPILE  TIME.  SUBSCRIPTION  IS 
PERFORMED,  BUT  IT  COULD  CAUSE  A  RUN  ERROR. 

XP26:  EXPRESSION  TOO  COMPLEX  TO  COMPILE.  COMPILER  HALTS.  TRY 
ASSIGNING  TO  TEMPORARY  VARIABLES  SO  THE  EXPRESSION  IS  NOT 
SO  COMPLEX. 

XP27:  ATTEMPT  TO  DEREFERENCE  OTHER  THAN  POINTER.  DEREFERENCING 
IS  PERFORMED,  BUT  RESULT  IS  MEANINGLESS. 

XP28:  FIELD  SELECTOR  IS  NOT  THE  NAME  OF  A  FIELD  IN  A  RECORD.  THE 
FIRST  FIELD  OF  THE  RECORD  IS  USED. 
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XP29 :  FIELD  SELECTION  IS  ATTEMPTED  ON  A  VARIABLE  WHICH  IS  NOT  A 
RECORD.  FIELD  SELECTION  IS  PERFORMED,  BUT  RESULT  IS 
MEANINGLESS. 

XP30 :  INCORRECT  ARGUMENT  TYPE.  THE  VALUE  OF  THE  ARGUMENT  IS 
CONVERTED  TO  THE  TYPE  OF  VALUE  EXPECTED  BY  THE  SUBPROGRAM 
AND  IS  USED. 

XP31  INVALID  ARGUMENT  FOR  "REFER",  "CVCI",  "CVIC" ,  "CVBI" ,  or 
"CVIB".  THE  VALUE  OF  THE  ARGUMENT  IS  CONVERTED  TO  THE  TYPE 
OF  VALUE  EXPECTED  BY  THE  SUBPROGRAM  AND  IS  USED. 

XP32:  ATTEMPT  TO  COMPARE  TWO  EXPRESSIONS  OF  DIFFERENT  TYPES. 

RELATIONAL  OPERATION  IS  PERFORMED,  BUT  THE  RESULT  IS 

MEANINGLESS. 

XP33:  INVALID  RELATIONAL  OPERATOR  FOR  BIT  OR  POINTER  TYPES. 

RELATIONAL  OPERATION  IS  PERFORMED,  BUT  THE  RESULT  IS 

MEANINGLESS. 

XP34 :  MISSING  "[ "  OR  "]"  AFTER  " ALLOC”.  "[ "  OR  "]"  IS  GENERATED. 

XP35:  INCORRECT  NUMBER  OF  ARGUMENTS  FOR  AN  OPERATOR.  OBJECT 

PROGRAM  NO  EXECUTABLE. 

XP36 :  ATTEMPT  TO  ALLOCATE  SOMETHING  OTHER  THAN  A  RECORD  WITH  THE 
ALLOC  FUNCTION.  ALLOCATION  IS  DONE,  BUT  RESULT  CANNOT  BE 
USED. 


I 
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Appendix  C 


Compiler  Options 


Listing  of  source  code  and  subscript  checking  can  be  turned 
on  or  off  by  setting  or  clearing  "control  toggles".  This  is  done 
by  placing  the  following  in  a  comment: 

&1  :  turns  on  source  listing 

&-»L  :  turns  off  source  listing 

SS  :  turns  on  subscript  checking 

6-«S  :  turns  off  subscript  checking 

For  example,  the  following  comment  will  be  printed,  but  not 
those  statements  following  it  (until  an  SL  is  found) : 

%  turn  off  source  listing  G-*L 

Initially,  both  listing  and  subscript  checking  are  turned  on. 


85 


Appendix  D 

The  ASCII  Character  Set 

The  octal  code  of  each  character  in  the  ASCII  character  set 
is  given  in  the  table  below.  The  table  below  also  indicates 
which  characters  can  be  generated  on  the  teletype  and  how  these 
characters  can  be  generated  from  the  teletype  keyboard. 

ASCII  CHARACTER  SET 


7-Eit 

Octal 

Code 

Character 

Remarks 

000 

NOL 

NOLL,  TAPE  FEED,  CONTROL/SHIFT/P. 

001 

SOH 

START  OF  HEADING:  ALSO  SOM,  START  OF 

0-0  2 

STX 

MESSAGE,  CONTROL/A. 

START  OF  TEXT;  ALSO  EOA,  END  OF  ADDRESS 

003 

ETX 

CONTROL/E. 

END  OF  TEXT;  ALSO  EOM,  END  OF  MESSAGE, 

004 

EOT 

CONTROL/C. 

END  OF  TRANSMISSION  (END) ;  SHOTS  OFF 

005 

ENQ 

TWX  MACHINES,  CONTROL/D. 

ENQOIRE  (ENQRY) ;  ALSO  WRU,  CONTROL/E. 

006 

ACK 

ACKNOWLEDGE;  ALSO  RO ,  CONTROL/F. 

007 

BEL 

RINGS  THE  BELL.  CONTROL/G. 

010 

BS 

BACKSPACE;  ALSC  FEO,  FORMAT  EFFECTOR. 

011 

HT 

BACKSPACES  SOME  MACHINES.  CONTROL/H. 
HORIZONTAL  TAB.  CONTROL/I. 

012 

LF 

LINE  FEED  OR  LINE  SPACE  (NEW  LINE) ; 

013 

VT 

ADVANCES  PAPER  TO  NEXT  LINE,  DOPLICATED 
BY  CONTROL/J. 

VERTICAL  TAB  (VTAB) •  CONTROL/K. 

014 

FF 

FORM  FEED  TO  TOP  OF  NEXT  PAGE  (PAGE) 

015 

CR 

CONTROL/!. 

CARRIAGE  RETURN  TO  BEGINNING  OF  LINE. 

016 

SO 

DOPLICATED  BY  CONTROL/M. 

SHIFT  OOT;  CHANGES  RIBBON  COLOR  TO  RED. 

017 

SI 

CONTROL/N. 

SHIFT  IN;  CHANGES  RIBBON  COLOR  TO  BLACK. 

0  20 

DLE 

CONTROL/O. 

DATA  LINE  ESCAPE.  CONTROL/P.  (DC0) . 

021 

DC1 

DEVICE  CONTROL  1,  TURNS  TRANSMITTER 

022 

DC2 

(READER)  ON,  CONTROL/Q(X  ON). 

DEVICE  CONTROL  2,  TURNS  PUNCH  OR 

023 

DC3 

AUXILIARY  ON.  CONTROL/R  (TAPE,  AUX  ON). 
DEVICE  CONTROL  3,  TURNS  TRANSMITTER 

024 

DC4 

(READER)  OFF,  CONTROL/S  (X  OFF). 

DEVICE  CONTROL  4,  TURNS  PUNCH  OR 

025 

NAK 

AUSILIAR  Y  OFF,  CONTROL/T  (AUX  OFF). 
NEGATIVE  ACKNOWLEDGE;  ALSO  ERR,  ERROR. 

026 

SYN 

CONTROL/U. 

SYNCHRONOUS  FILE (SYNC) .  CCNTROL/V. 

027 

ETB 

END  OF  TRANSMISSION  BLOCK;  ALSO  LEM, 
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030 

CAN 

LOGICAL  END  OF  MEDIOM.  CONTROL/W. 
CANCEL  (CANCEL).  CONTROL/X. 

031 

EM 

END  OF  MEDIOM.  CONTROL/Y. 

032 

SOB 

SOBSTITOTE.  CONTROL/Z. 

033 

ESC 

ESCAPE.  CONTROL/SHIFT/K. 

034 

FS 

FILE  SEPARATOR.  CONTROL/S HIFT/L. 

035 

GS 

GROOP  SEPARATOR.  CONTROL/SHIFT/M. 

036 

RS 

RECORD  SEPARATOR.  CONTROL/SHIFT/N 

037 

OS 

ONIT  SEPARATOR.  CONTROL/SHIFT/O. 

040 

SP 

SPACE. 

041 

! 

042 

it 

043 

# 

044 

$ 

045 

% 

046 

6 

047 

t 

ACCENT  ACOTE  OR  ASPOSTROPHE. 

050 

( 

051 

) 

052 

* 

053 

+ 

054 

i 

055 

* 

056 

• 

057 

/ 

060 

0 

061 

1 

062 

2 

063 

3 

064 

4 

065 

5 

066 

6 

067 

7 

070 

8 

071 

9 

, 

072 

• 

• 

073 

• 

f 

074 

< 

075 

= 

076 

> 

077 

• 

100 

S 

101 

A 

102 

B 

103 

C 

104 

D 

105 

E 

106 

F 

107 

G 

1  10 

H 

111 

I 

112 

J 

113 

K 

- 

114 

L 

115 

M 

87 


1  16 
117 
120 
121 
122 

123 

124 

125 

126 
127 

130 

131 

132 

133 

134 
1  35 

136 

137 

140 

141 

142 

143 

144 

145 

146 

147 

150 

151 

152 

153 

154 

155 

156 

157 
160 
161 
162 

163 

164 
1  65 
166 
167 

170 

171 

172 

173 

174 

175 

176 


N 

0 

P 

Q 

R 

S 

T 

0 

V 

w 

X 

Y 
Z 
[ 


1 

I 

<- 


a 

b 

c 

d 

e 

f 

g 

h 

i 

3 

k 

1 

m 

n 

o 

P 

q 

r 

s 

t 

u 

V 

w 

X 

y 

z 

{ 

I 

} 


177  DEL 


SHIFT/K. 

SHIFT/L. 

SHIFT/M. 

DP  AEEOW .  SHIFT/N 

ACCENT  GEAVE. 

* 

4c 

4c 

4c 

4c 

4c 

4c 

4c 

4c 

4c 

4c 

4c 

4c 

4c 

4c 

4c 

4c 

4c 

4c 

4c 

4c 

4c 

4c 

4c 

4c 

4c 

4c 

4c 

THIS  CODE  GENEEATED  BY  ALT  MODE. 
THIS  CODE  GENEEATED  BY  PEEFIX  KEY 
(IF  PRESENT)  . 

DELETE,  ROB  OUT. 


*  AN  ASTERIK  BESIDE  A  CHARACTER  INDICATES  THAT  IT  CANNOT 
BE  GENERATED  BY  THE  TELETYPE. 
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1  ?0  THIS  PROGRAM  CALCULATES  THE  AVG  MARK  IN  A  CLASS. 

2  IT  IS  DONE  TN  THE  FOLLOWING  WAY; 

3*1.  THE  NUMBER  OF  STUDENTS  IN  THE  CLASS  IS  READ. 

4  ?,  2.  THE  NAME  .OF  EACH  STUDENT  IN  THE  CLASS  ANd  HIS  MARK  AR£  READ. 

5  %  (IN  FORMAT:  NAME. 3  DIGIT  MARK  E.G.:  J0HN»685  ) 

6  ?;  3.  THE  NAME  OF  EACH  STUDENT  IN  THE  CLASS  AND  HIS  MARK  ARE  PRINTED. 

7  *  4.  THE  AVG  MARK  IS  CALCULATED  AND  IS  PRINTED. 

e 

9  literal  tty='o» 

10  literal  lp=»i» 

11 
12 

13  PROCEDURE  main 

14  DECLARE'-  - 

15 

16  CRJCHARACTEP 

17  SUM .NU'NNUMr. MARK* J  »J»NUMCHR: INTEGER 

18  A  :aRRAYCP01  of  CHARACTER 

19  GmARk:  FUNCTION  CARRAYC  803  OF  CHARACTER, INTEGFR3  RETURNS  INTEGER 

20 

21  END  DECLARE 

22  • 

23 

24  CR:=CVJCC133  %  CR  IS  THE  CARRIAGE  RETURN  CHARACTER 

25  sum:=o 

26  urc 'ENTER  MUMPER  OF  STUOFNTS I • , 25 , TT Y 3 

27  MUM:  =  IICTTY3  READ  NUMBER  OF  STUDENTS 

28  IMLMC  S=NUM  %  INITIALISE  A  COUNTER 

29 

30  %  PRINT  THE  FOLLOWING  MESSAGE 

31  A:=»NAME  OF  STUDENT  MARK 

32  OACA,55,LP3 

33  UCCCK.TTY3 

34  OCC  CR ♦ LP  3 

35  • 

36  ?6THIS  LOOP  RFADS  AND  PRINTS  THE  NAME  AND  MARK  Op  EACH  STUDENT 

37  LOOP  WHILE  NU«C>0 

38 

39  %READ  NAME  AND  MARK  OF  STUDENT 

40  IaCa»NUHCHR,TTY3 

41  j:=o 

42 

43  SPRINT  NAME  OF  STUDENT  ON  THE  LINE  PRINTER 

44  LOOP  WHILE  ( AC J 3~= • » • ) £ ( J<NUMCHR ) 

45  OCC  AC  J.3  ,  LP  3 

46  j:=j+i 

47  REPEAT 

48 

49  2STEST  FOR  V'VLID  DATA 

50  J:=J  +  1  SKSKIP  OVER 

51  IF  J>=NUMCHR 

THEN  «  *  ERROR  IN  DATA 

OCC  CR  »  TT Y  3 

A:=»  ERROR  IN  DATA  • 

0ACA,1S,TTY3  3  PRINT  MFSSAGE  ON  TTY 


52 

53 

54 

55 
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56  EXIT  >> 

57  ELSE  MARKj=GMARKCA» J3  %  CALCULATE  MaRK  FROM  CHARACTER  STRING 

58 

59  SUM:=SUM+MARK  %  ADD  MARK  TO  CUMULATIVE  TOTAL 

60  II=J 

61  LOOP  WHILE  I<40  %  THIS  LOOP  FORMATS  THE  OUTPUT 

62  OCC'  LP3 

63  I : =1+1 

64  REPEAT 

65 

66  ?nPR  I  NT  MARK  OF  STUDENT 

67  OCCACJJ.LP  DJOCCAC J+l DtLP  3 ; OCC AC J  +  2 3 » LP  3 

68  OCCCR.LP3 

69  !\IUMc:=NUMC-l  “^DECREMENT  COUNTER 

70 

71  REPEAT 

72 

73  hi  ARK  I  =SUM/NUM  •  ^CALCULATE  AVG  MARK 

74  a:=*average  MARK  IS 

75  OA  C  A  » 15  t  Lp  3 

76  0 1 C  M ARK  «  LP  3 

77  OfCCR,LP3  ‘ 

78 

79 

80  EMO  MAIN 

81 
82 

83  # 

84 

85  FUNCTION  GMARkCS: array:  803  OF  CHARACTER*  .  « 

86  K:  INTEGER  3  RETURNS  INTEGER 

87 

88  ?o  THIS  FUNCTION  CALCULATES  THE  MARK  GROM  THE  CHARACTER  STRING 

89 

90 

91  DECLARE 

92  N.’HI  INTEGER 

93  Ef D  DECLARE  * 

94 

95  n:=o 

96  I  j : =0 

97 

93  Si  THIS  LOOP  CALCULATES  THE  MARK 

99  LOOP  WHILE  N<=2 

100  M  :=M*10+CVCICt3CK+N33-CVCIC  ♦0*3 

101  n:=n+i 

102  REPEAT 

103 

104  RETURN  M 

105 

106  END  GMARK 

107  $ 

XFER  APDR  046264 


NAME  OF  STUDENT  MARK 

JOHN  500 

PETER  700 

HARRY  650 

JIM  475 

BOBBY  flOO 

AVERAGE  MARK  Is  625 


ENTER  NUMBER  OF  STUDENTS: 5 

JOHN, ODD 
PETER, 700 
HflRR V,  650 
JIM,  475 
BOBHV, 800 
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1  %  FACTORIAL 

2 

3  %  THIS  PROGRAM  READS  ['JUMPERS  ON  THE  TELETYPE  AND  PRINTS  THERE  FACTORIAL. 

4  £  IT  WILL  REPTAT  UNTIL  A  NEGATIVE  NUMBER  IS"  INPUT.  INPUTS  >  =  8  WILL  CAUSE 

5  OVERFLOW,  SO  THE  ANSWER  WILL  BE  WRONG, 

G 

7  LITERAL  tty=»q» 

6 

9  REENTRANT  FUNCTION  FACTC I : INTEGER]  RETURNS  INTEGER 

10  DECLARE 

11  FACT :F UN cTIONC INTEGER]  RETURNS  INTEGER  * 

12  END  DECLARE 

13 

14  if  i<=o  then  return  i 

15  FLSF  RETURN  FaCTCI-iD*I 

16  end  fact 

17 

18  PROCEDURE  MAIN 

19  DECLARE 

20  I : INTEGER 

21  FACT : FUNCTTGNC INTEGER  3  RETURNS  INTEGER 

22  LT  D  DECLARE 

23 

24  0  ^ C *  ENTER  NUMBER : * » 1 3 » TT Y  D 

25  i:=IirTTYT 

26  LOOP  WHILE  I>  =  0 

27  oici.tiy: 

28  OAC • !=• ,?,TTYD 

29  OICFACTC I D.TTYD 

30  OCCCVTCE13T, TTY D 

31  OAC’ENTER  NUnBER: • .13.TTY3 

32  i:=iictty: 

33  REPEAT 

34  end  main 

35  3,  . 

XFER  A-PDR  046264 


ENTER 

NUMBER : 4 

4  !  = 

24 

ENTER' 

NUMBER : 5 

5!  =  1 

20 

ENTER 

NUMBER : 2 

2  !  = 

2 

ENTER 

NUMBER : 3 

ENTER 

NUMBER : 0 

0!  = 

1 

ENTER 

NUMBER: -1 
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1 

2 

3 

4 

5 

6 
'  7 

8 

9 

10 

11 

12 

13 

14 

15 

16 
17 
16 

19 

20 
21 
22 

23 

24 

25 

26 

27 

28 

29 

30 

31 

32 


33 

34 

35 

36 

37 

38 

39 

40 

41 

42 

43 

44 

45 

46 

47 

48 

49 

50 

51 

52 

53 

54 

55 


%  SQUARES 

• 

?-TH I S  PROGRAM  CALCULATES  THE  SQUARE  OF  THE  INTEGERS  FROM  0  TO  10. 
f-  I T  USES  AN  OPERATOR  CALLED  MUL,  Ml IL  PERFORMS  THE  MULTIPLICATION 
^OPERATION  P^TWEEM  TWO  8  BIT  INTEGERS.  MUL  USES  THE  SHIFT  AND 
?,ADD  MULTIPLICATION  ALGORITHM  TO  PERFORM  THE  MULTIPLICATION, 

LITERAL  CR=»CVlCCi3T»  8  CR  IS  THE  CARRIAGE  RETURN  CHARACTER 


procedure  main 

DECLARE 

t«j: integer 

A : ARRAYC80 D  OF  CHAP ACTFR 

muljoperatopcinteger, integers  returns  integer 

END  DECLARE 


OrCcRfOD 
i :  =  0 


8PRINT  CR  ON  THE  TELETYPE 

^initialise  counter 


LOOP  WHILE  I<=10 
J:=I  MUL  I 
otci.ot 

a:='  squared  is  : 

MAC  A  » 1A , 0  3 
0  T  C  J  .  0  3 

f'CC  CR  »  0  3  ;  OCT  CR  .  0  3 
T : = I +l 

REPEAT  * 


jrJ  IS  ASSIGNED  THE  SQUARE  OF  I 

8 PR I NT  I  ON  THE  TELETYPE 

* 

’.'PRINT  MESSAGE  ON  THE  TELETYPE 
9-PRINT  J  ON  THE  TELETYPE 
’  PRINT  CR  *  S  ON  the  teletype 
9INCPEMENT  COUNTER 


end  main 


OPERATOR  MULCX: INTEGER »Y: integer  3  RETURNS  INTEGER 

9' THIS  OPERATOR  MULTIPLIES  TWO  INTEGERS.  IT  USES  THE  SHIFT  ANp  ADD 
’.'ALGORITHM  TO  PERFORM  THE  MULTIPLICATION.  NOTE  THAT  EACH  OF  THE 
'OPERANDS  MUST  FIT  IN  p  BITS.  THE  RESULT  OF  THE  MULTIPLICATION 
Vo  IS  AM  INTEGER  (lb  BITS). 


declare 

H :  B ITS 

1 1 k  :  integer 
sum: integer 

END  DECLARE 


?o H 0 L D S  THE  SHIFTED  MULTIPLIER 
9'HOLDS  THE  PARTIAL  SUM 


I  :=x 

b:=cvibcY3 
k:  =  i 
sum:=o 


9'HOLDS  the  multiplicand 
‘.'HOLDS’  THE  MULTIPLIER 
’r'INtTIALlSE  COUNTER 
9«  I N I T I  A 1. 1 S E  SUM 


LOOP  WHILE  K<=8 

OMEN  B  then  sum:=sum+ 


’/THIS  LOOP  PERFORMS  THE  SHIFT  AMD  AOD  ALGORITHM. 

I  %TF  LOW  ORDER  BIT  OF  THE  SHIFTED  MULTIPLIER  IS 

?AONE  THEN  ADD  SHIFTED  MULTIPLICAND 
^INCREMENT  COUNTER 


K :=K+1 
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56  I  :=CVPlCASLCCVlnCI  111  “/SHIFT  MULT  I  PL  IC  AND  .  NOTE  THAT  THE 

57  *SHJFT  FUNCTION  OPERATES  ONLY  ON  BIT  VARIABLES 

56  n:=ASRCBI  “/SHIFT  MULTIPLIER  ONE  PLACE  RIGHT 

59  REPEAT 

60 

61  RETURN  SUM  "-return  PRODUCT  TO  CALLING  PROGRAM 

62 

63  END  MUL 

64  $ 

XFER  ADDR  046264 


0 

SQUARED 

IS  : 

0 

1 

•SQUARED 

IS  : 

1 

V™, 

sL 

SQUARED 

IS  : 

4 

SQUARED 

IS  : 

9 

4 

SQUARED 

IS  : 

16 

5 

SQUARED 

IS  : 

25 

6 

SQUARED 

IS  : 

36 

—n 

1 

SQUARED 

IS  : 

49 

8 

SQUARED 

IS  : 

64 

Q 

SQUARED 

IS  : 

81 

10 

SQUARED 

IS  : 

100 
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1 

2 

3 

4 

5 

6 

7 

8 
9 

10 

11 

12 

13 

14 

15 

16 

17 

18 

19 

20 
21 
22 

23 

24 

25 

26 

27 

28 

29 

30 

31 

32 

33 

34 

35 

36 

37 

38 

39 

40 

41 

42 

43 

44 

45 

46 
4  7 

48 

49 

50 

51 

52 

53 

54 

55 


ss  read  and  sort  words 

%  THIS  PROGRAM  ILLUSTRATES  TWO  USES  OF  MODULES: 

%  VCHAR-MOD  IS  USED  to  DEFINE  A  VARYING  CHARACTER  TYPE  AND  SOME 

%  OPERATIONS  ON  IT. 

%  S0RT_MOn  IS  USED  TO  DEFINE  A  SORT:  ONLY  THE  SORT  PROCEDURE  IS 

%  VISIBLE  OUTSIDE  THE  MOP.ULE,  HIDING  THE  FACT  THAT  A  HEAPSORT  IS  USED  t 

%  and  that  various  support  routines  are  needed. 

LITERAL  LP= ' 1  * 

LITERAL  TTY= ' 0 ' 

LITERAL  CR='CVICCl3D» 

LITERAL  ,'fl  AXLENGTHs  *15' 

MODULE  VCHAR-OOD  imports  lp »tty,cr ,maxlength  #  • 

EXPORTS  READvC .WRITE VC ,  V ARCH AR  tVCLESS 

TYPE  VARCHAR  =  REC CROC L E NGTH : INTEGER  .CHARS: ARP AYCMAXLEMGTH 3  OF  CHARACTER  1 


FUNCTION  READVC  RETURNS  POINTER  TO  VARCHAP 

%  THIS  FUNCTION  READS  A  WORD  (LETTER?  FOLLOWED  BY  A  CR)  PROM  THE 
%  TELETYPE,  ALLOCATES  STORAGE  FOP  A  •VARCHAP',  AND  FILLS  IT  WITH 
%  WORD  WHICH  WAS  READ.  INITIALIZING  THE  LENGTH. 

DECLARE 

PJPOINTFR  TO  VARCHAR 
1 1  INTEGER 
END  DECLART 
p:=ALLOCC VARCHARD 
OCC • : • , TTY  3 

lACffP. CHARS , I ,TTY3  % 

%  I  CONTAINS  THE  NUMBER  OF  CHARACTERS 
%  SUBTRACT  1  FROM  IT  TO  GET  LENGTH  OF 

eP.length:=i-i 

RETURN  P 
END  READVC 


THE 


%  ALLOCATE  SPACE  FOR  NEW  WORD 
%  PROMPT  FOR  THE  WORD 
95  RFAD  IN  THE  WORD 

RE  AD ,  INCLUDING  THE  CR. 

WORD 


PROCEDURE  WRITFVCCPJFOINTER  To  VARCHAR  3 

%  THIS  PROCEDURE  WRITES  THE  WORD  IN  THE  VARYING  CHARCTFR  VARIABLE 
%  POINTED  AT  BY  P,  ON  THE  LINE  PRINTER. 

DECLARE 

i : integer 

END  DECLARF  ' 
i :  =  0 

LOOP  UNTIL  i=@p. length 

OCCfaP.CKARSC  I  3  ,LP3  Sc  OUTPUT  A  CHARACTER  OF  IT 

i :=i+i 
REPEAT 
END  WRITEVC 


OFT^ATOR  VCLESSCPi  :PCINTER  to  VARCHAR, P2:P0IiMTER  TO  VARCHAR3  RETURNS  BITS 
%  THIS  OPERATOR  CAN  FE  USED  TO  COMPARE  TWO  VARYING  CHARACTER  VALUES, 

%  RETURNING  'TRUE*  IF  THF  FIRST  IS  LESS  THAN  THE  SECOND  (ALPHABETICALLY). 
DECLARE  . 

I : INTEGER 
END  DECLARE 
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56  I : =0 

57  LOOP  UNTIL  I=3P1. LENGTH 

58  IF  ( I=3P2. LENGTH)  !  (  Si  P 1 . CHArSC I ]>3P2 . CHARSC  I  ] )  THEN  RETURN  FALSE 

59  ELSE  WHFN  SIP  1 .  CHARSC  I  K3P2  .  CHARSC  I  ]  THEN  RETURN  TRUE 

60  I:=I+1 

61  REPEAT 

62  RETURN  TRUE 

63  ENn  VcLESS 

64 

65  end  vchaR_hod 

66 

67 

68  DATA  W0RD.DAT  %  HOLDS  THE  WORDS  THEMSELVES 

69  DECLARE 

70  WORDS  I ApPA YC 1  TO  100]  OF  POINTER  TO  VARCHAR 

71  nhokds: integer 

72  END  DECLARE 

73  Ern  WORD-DAT 


74 

75 

76  MODULE  SORT.tfor)  IMPORTS. VARCHAR «VCLESS»WORD_DaT  »m/\XLENGTH  4 

77  EXPORTS  SORT 

78 

79  pr  t'CEDURF  SORT 

80  %  THIS  PROCEDURE  USES  A  PEAPSO^T  TO  SORT  THE  WORDS  IN  WORD-DATf 

81  %  using  The  OPERATOR  vclfss  To  COMPARE  words. 

82  ?0  1  1 1 1 L  P  H  E  A  P  IS  USED#  INITIALLY  TO  BUILD  A  HEAP  OUT  OF  THE  WORDS 

83  *  ("HERE  SONS  ARE  AL  t  AYS  LESS  THAN  THEIR  PARENT).  THEM  THE  TOP  ELEMENT 
64  5c  T  S  REPEaTEDI  Y  MOVED  TO  THE  END  (Sl^'CE  IT  IS  LARGEST)  A^O  HEAPIFY  IS 


85 

6b 

87 

88 

89 

90 

91 

92 

93 

94 

95 

96 

97 

98 

99 
100 
101 
102 

103 

104 

105 


%  used  to  reform  a  hfap. 

DECLARE 

WORDS  :ApRAYC 1  TO  100T  OF  POINTER  TO  VARCHAR  FROM  WORD, OAT 
NWORDS  I  INTEGER  FROM  WOPD-DAT 
BUI LGHEaP: PROCEDURE  • 

HEAPIFY ;PR0CEDUP EC  INTEGER i INTEGER] 

IIINTEGpR 

PJPoINTPR  To  VARCHAR 
END  DECLARE 

UUILDUEAP  %  START  OFF  WITH  A  HEAP 

I :=NWORDS 
LOOP  UNTIL  I <2 

%  SuaP  UORDSC 1 ]  AND  WOPDSC I D 

p:=wordsci] 
wordsci t:=wordsc i  ] 
wor<DScn:=p 

HEAPIFYC 1 ♦ I-l]  S  AND  REPEAT  FOR  PEST  OF  LIST 

I :  =  i  - 1 
REPEAT 
ET  0  SORT 


106  PR ('CEnURE  BUIl  DUE AP 

107  %  FORM  A  HEAP  FROM  THE  UNSORTED  WORDS 

108  DECLARE 

109  I :  INTEGTR 
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no  nwords: integer  from  word-DAT 

hi  hearify: procedures  integer  ,  integers 

112  end  declare 

113  T  :=NWORf)S/2 

114  LOOP  UNTIL  I<1 

115  HEAPIFYF I .NWORDS] 

116  I S  =1-1 

117  REPEAT 

118  END  BUILUHEAP 

119 


120  rffmtrant  procedure  heapifyc i  :  integer ,j: integer] 

121  %  maKE  SURE  the  list  from  i  to  j  is  a  heap 

122  DECLARE 

123  -  k: integer  

124  PiPOINTFR  To  VAPCHAR 

125  WORDS: AT RAYC 1  TO  1001  OF  POINTER  TO  VARCHAR  FROM  WORD-DAT 

126  NWORDS: INTEGER  FROM  WORD-PAT 

127  HEAPIFY:  PROCEDURE!:  INTEGER  .INTEGER] 

128  VC LESS! OPERA  TORT  POINTER  TO  VARCHAR. POINTER  TO  VARCHaR]  RETURNS  BITS 

129  END  DECLARE 

130  WHEN  I<  =  J/P  THEN  <<  ?!  IF  I  IS  NOT  A  LEAF 

131  k:=i 

132  WHEN  (WORDSCK3  VCLESS  W'ORDSC  2*  I  2  )  THEN  KJ=2*I 

133  WHFN  2* I < J  THEN  ft 

134  WHEN  ( WORDS! K  I  VCLESS  WOROSC 2*1  +  13)  THEN  KJ=2*I+1 

135  %  IF  A  SON  IS  GREATER  THAN  WOROSC 1 1  THEN  INTERCHANGE  THE 

136  %  larger  son  (son  k»  with  wordscid 

137  WHEN  K~  =  T  THEN  << 

138  p:=WORDSCn 

139  wORDSC I d:=wordsckd 

140  WORDSrK3:=P 

141  HEAPIFYCK.  J] 

142  » 

143  >> 

144  END  HEAPlFY  , 

145 

146  ENn  SORT-MOD 


147 

148 

149  PROCEDURE  MAIN 

150 

151  *  THIS  is  THE  DRIVER  PROCEDURE  FOR  The  PPOGRAM. 

152  %  IT  ASKS  FOR  THE  NUF&ER  OF  WORDS  TO  bF  SORTED.  THEN  READS  THEM  IN 

153  %  (USING  READVC).  SORTS  THEM  (USING  SORT)  AND  PRINTS  THE  SORtEO  LIST. 

154 

155  DECLARE 

156  NWORDS : INTEGER  FROM  WOPD-DAT 

157  WORDS : APRAYC 1  TO  ICO]  OF  POINTER  TO  VARCHAP  FROM  WORO_DAT 

158  sort:procedure 

159  PEADVC:FUNCTI0M  RETURNS  POINTER  TO  VARCHAR 

160  WRTTEVC : PROCEDURE! PO INTER  TO  VARCHAR] 

161  I : INTEGER 

162  END  DECLARE 

163  OAC •NUMBER  OF  WORDS 16 . TTY] 
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164  MWORDS:=IICTTYD 

165  i : =1 

166  loop  while  i<=nwords 

167  WOHDSC I 3:=READVC 

168  I S  =1  +  1 

169  REPEAT 

170  SOrT 

171  I : =1 

172  LOOP  WHILE  I<=NWORDS 

173  WRITEVCTWORDSC I 3  3 

174  OCC  CR  «  LP  D 

175  IS=I+1 

176  REPEAT 

177  Er  0  MAIN 

178  $ 

XFER  AT  OR  046264 


85  READ  A  WORD 

%  SORT  THE  WORDS 

%  WRITE  A  WORD 

%.  AND  GO  TO  NEXT  LINE  ON  PRINTER 


BOMB 

COMPUTE 

COMPUTER 

DOG 


HUMBER  OF  WORDS: 4 
:  COMPUTER 
;  DOG 

: COMPUTE 
:  BOMB 
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1  %  table  of  numbers 

2 

3  %  THIS  PROGRAM  INSERTS  NUMBERS  INTO  A  TABLE  (TO  INSERT  A  NUMBER » 

4  %  TYPE  I  5 »  FOR  EXAMPLE  *  WHICH  INSERTS  5).  TYPING  S  WILL  STOP  THE  PROGRAM 

5  %  after  pkintt-ng  THE  TABLE  CONTENTS.  THE  TABLE  IS  ordereo, 

6 

7  %  THE  PROGRAM  ILLUSTRATES  THE  USE  OF  A  MODULE  TO  DEFINE  A  TYPE  'PTRSTaCK* 

8  So  (WHICH  IS  A  STACK  OF  POINTER  TO  RECORD),  AND  OPERATIONS  ON  IT. 

9 

10  %  ANOTHER  MODULE  IS  USED  TO  DEFINE  A  »TABLE»  TYPE,  WITH  THE  OPERATIONS 

11  *  T  N I T  *  «  ♦INSERT'  ,  AND  'PRINT  ♦  (PRINT  IN  ORDER).  THE  OUTSIDE 

12  %  ENVIRONMENT  DOESN'T  KNOW  TH/\T  A  BINARY  TREE  IS  USED  TO  IMPLEMENT 

13  So  THE  TABLE,  and  THAT  A  »PTRSTACK'  IS  USED  TO  DO.  AN  INORDER  TRAVERSAL 

14  So  OE  THE  TREE  WHEN  PPINTING  ELEMENTS. 

15 

16  MODULE  STK-MOn  EXPORTS  PTRST ACK , PUSH , POP . I M T , EMPTY 

17 

18  TYPE  PTRST ACK  =  R ECOR DT PLACE: INTEGER, LIST! A RRAYC 20  3  OF  POINTER  To  RECORD  1 

19 

20  PROCEDURE  I N I TC P : P TR ST ACK 3 

21  INITIALIZE  A  'PTRSTACK'  TO  BE  'EMPTY' 

22  DECLARE 

23  ENp  DECLARE 

24  p.place:=o 

25  END  I NIT 

26 

27  PROCEDURE  FUSmC  V  AL#:  P0 1 NTER  TO  RECORD , P : PTRST ACK 3 
26  So  PUSH  'VAL'  ONTO  THE  POINTER  STACK  P. 

29  DECLARE 

30  END  DECL  ARr 

31  WHEN  P • PL ACE>20  THEN  << 

32  OAC 'STACK  OVERFLOW ,14,03 

33  ABORT 

34  >>  • 

35  p. LISTCP.PL ACE3:=VAL 

36  p.place:=p.place+i , 

37  Er  0  PUSH 

38 

39  FUNCTION  POPCR :PTRSTACK :  RETURNS  POINTER  to  record 

40  s;  pop  a  value  off  of  the  ptrstack  p. 

41  DECLARE 

42  end  DECLARE 

43  P.PLACE:=P. PLACE-1 

44  WHEN  P.PLAOECO  THEN  << 

45  OAC 'STACK  UNDERFLOW ', 15 , 0 3 

46  ABORT 

47  >> 

48  RETURN  P  . L I STC P . PL  ACE  3 

49  El'D  POP 

50 

51  function  emptycp :ptrstack 3  RETURNS  bits 

52  So  THIS  FUNCTION  ALLOWS  THE  INSPECTION  OF  THE  STACK  STATUS. 

53  %  IT  RETURNS  TRUE  IE  THE  STACK  IS  EMPTY,  AND  FALSE  OTHERWISE. 

54  DECLARE 

55  END  DECLARE 
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56  IF  P.PLACE=0 

57 

58  e r ■  o  empty 

59 

60  Erin  stk-Mod 

61 
62 

63  MODULE  TABLEMOD 

64 

65 

66  LITERAL  Lp='l* 


THEN  RETURN  TRUE 
ELSE  RETURN  FALSE 


imports  ptrstack  *  pus w, pop, in  it, empty 
exports  insept, print ,  ini t_tab, table- 


n 


67 

66  TYPE  TABLE=RECORDCVAL : INTEGER,  U 

69  LSONIPOINTER  TO  RECORD,  « 

70  RSONIPOINTER  TO  RECORD  D 

71  ?'  ’TABLE'  IS  IMPLEMENTED  AS  A  BINARY  TREE 

72  *  THE  NODE  WHICH  IS  THE  ROOT  IS  ONLY  A  DUMMY  NODE,  WHOSE  RIGHT  SON  IS 

73  %  THE  REAL  ROOT  OF  THE  TREE  (THIS  GIVES  EVERY  NODE  A  FATHER). 

74 

75  PROCEDURE  I N I T_T ABC P : PO I NTER  TO  TABLED 

76  fc  INITIALIZE  THE  TABLE  POINTED  AT  BY  P  TO  BE  EMPTY 


77 

DECLARE 

78 

END  DECLARE 

79 

bp.rson:=null 

80 

Lr  D  I NIT-TAB 

81 

82 

PROCEDURE  iNSERTCNUr  :  I  MTEGER  ,  T_PTR  :  PO  INTER  TO  TABLED 

83 

V.  INSERT  'MUM'  INTO*  THE  TABLE  POINTED  AT  BY  '  T_PTR ' 

84 

declare 

85 

p,pfat:poimter  to  table 

86 

SONJCHARACTER 

87 

end  declare 

88 

V6  START  OFF  WITH  THE  ROOT.  THEN  DESCEND  THE  TREE  UNTIL  FIND 

AN 

89 

%  EMPTY  SPOT  FOR  *fUM'.  at  all  times,  pfat  POINTS  at  The  FATHER  of- 

90 

»  THE  CURRENT  node,  AnD  ‘SON  INDICATES  WHICH  SON  THE  CURRENT 

NODE  IS 

91 

pfat:=t_ptr 

92 

-  SOWS='K*  * 

93 

P:=5)T_PTR.F:S0N 

94 

LOOP  UNTIL  P  =  ()ULL 

95 

pfat:=p 

96 

IF  NUMCBP.VAL  THEN  « 

/ 

97 

p:=it.p.lson 

98 

som:=»l* 

99 

>> 

100 

else  << 

101 

p:=bp.rson 

102 

son:='r» 

103 

>> 

104 

REHEAT 

105 

p:=ALLOCCTABLED 

106 

5P,lson:=null 

107 

,ip.rson:=null 

108 

oip,val:=num 

109 

IF  S0'J='L*  THEN  6»PFAT  .  LSON  :  =P 
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110  ELSF  SPFAT.RSON:=P 

111  END  INSERT 

112 

113  PROCEDURE  printct.ptf ipointer  to  tabled 

114  a  PRINT  ALL  THE  NUMBERS  IN  THE  TABLE  POINTED  AT  BY  »T_PTR». 

115  %  THE  VARIABLE'  'STACK*  IS  OF  TYPE  'PTR STACK' ,  AND  IS  USED  TO  PUSH  A  NODE 

116  ONTO  A  STACK  WHILE  THE  LEFT  SON  TREE  IS  BEING  PRINTED.  WHEN  THAT  TREE 

117  %  IS  FINISHED,  THE  NODE  IS  POPPED,  AND  THE  NEXT  HIGHER  NODE  IS  DONE. 

118  DECLARE 

119  STACK IPTRSTACK 

120  INIT  I PROCEUIJREC PTRSTACK  3 

121  PUSH JPROCEDUREC POINTER  TO  TABLE , PTPSTACK 3 

122  POPiFUNCTIONCPTRSTACkD  returns  pointer  to  tab_le 

123  K  ACTUALLY,  IT  RETURNS  POINTER  TO  RECORD,  BUT  WE'LL  USE  IT  FOR  TarLES 

124  EMPTY  :  FUPJCTiONr  PTRSTACK3  RETURNS  BITS 

125  P  l  POINTER  TO  TABLE 

126  END  DECLARE 

127  • INITCSTACKD 

128  P:=aT_PTR.PSON  55  START  P  AT  ROOT 

129  loop  while  true 

130  if  p*=null  then  << 

131  -PUSHCP, STACK]* 

132  P!=r3P.LSOW 

133  >> 

134  ELSE  IF  FMPTYCSTACK 3  THEN  RETURN 

135  ELSE  << 

136  P  t  =POPC  STACK  3 

137  OTCciP.VAL  ,LP3 

136  OGCCVICC 133, LP3 

139  P:=DP,RSON 

140  >> 

141  REPEAT 

142  LND  PRINT 

143 

144  END  TABLEMOD 

145 


146  PROCEDURE  MAIN 

147  S.  THIS  IS  THE  DRIVER  PROCEDURE. 

146  IT  DECLARES  'NUMTAP'  TO  RE  A  TABLE,  INITIALIZES  IT,  INSERTS  NUMBERS 

149  SS  Ir'TO  IT  AS  I  ONG  AS  INSERT  COMMANDS  ARE  ENTERED,  AND  THEN  PRINTS  THE  TAR|_E. 


150  DECLARE 

151  1 1 J I  T  _  T  A  P : P  D  C  C  E  D  t 1 R  E  T  P  0  I N  T  E  R  To  T  ABLE  3 

152  .INSERT : PROCEDURE C INTEGER, POINTER  TO  TABLE  3 

153  .  PR  I  NT : PROCEDURE  C  PO INTEP  TO  TABLED 

154  NUMTAB STABLE 

155  CHJCHARACTER 

156  END  DECLARE 

157  I N  I  T_TaBC  RrFFRr  NUMT  AB  3  3 

156  CHlrICCOD  %  READ  A  COMMAND  CHARACTER 

159  LOOP  WHILE  CH*='S' 

160  WHEN  CHr'I*  THFr  INSERTC IIC 0  ]*PEFERCNUMTAB]] 

161  ch:=iccod 

16?  REPEAT 

163  PRINTCREFEPCNUMTAB33 
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164  END  MAIN 

165 

166  * 

XFER  aDDR  046264 
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F.  Lochovsky  and  D.  Tsichritzis,  May  1974  [INFOR, 
to  appear] 

*  CSRG-34  ALLOCATING  STORAGE  IN  HIERARCHICAL  DATA  BASES 
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RELIABLE  SOFTWARE 

David  B.  Wortman  (ed.),  September  1974 

*  CSRG-42  THE  PROJECT  SUE  SYSTEM  LANGUAGE  REFERENCE  MANUAL 

B.L.  Clark  and  F.J.B.  Ham,  September  1974 


CSRG-43  A  DATA  BASE  PROCESSOR 
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CSRG-48  DETERMINISTIC  LEFT  TO  RIGHT  PARSING 

Christopher  J.M.  Turnbull,  January  1975 
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J.V.  Guttag  (ed. ) ,  Third  Edition,  April  1975 

CSRG-55  STRUCTURED  SUBSETS  OF  THE  PL/1  LANGUAGE 

Richard  C.  Holt  and  David  B.  Wortman,  May  1975 
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CSRG-67  A  DIAGRAMMATIC  APPROACH  TO  PROGRAMMING  LANGUAGE 
SEMANTICS 

James  R.  Cordy,  March  1976  [M.Sc.  Thesis,  DCS,  1976] 
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E.A.  Ozkarahan  and  S. A.  Schuster,  October  1976 

CSRG-75  DO  CONSIDERED  OD:  A  CONTRIBUTION  TO  THE 
PROGRAMMING  CALCULUS 
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